-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey,
I just finished having a conversation with Ann Harrison on this list.
Jim and her (and maybe others its been a while since I read the
Interbase story) were the first architects of Interbase (predecessor to
Firebird). Anyways, long story short. Check my conversation with her,
on this list. Thread: Firebird BLOB vs. Filename Storage . I just
finished talking to her about the current state of how transactions are
left in a crash.

But I totally agree with you that it would DEFINETELY be useful if the
database was ALWAYS left in a consistent state. From what I hear from
Anne, crashes during data manipulation will usually leave a consistent
database.

Edward Flick

Jonathan Neve wrote:

| Hi!
|
| I'm posting this here instead of in the FireBird-Architect group,
| because I posted it there this morning, and it still hasn't showed up...
|
| Could anyone please give me a detailed explanation (or perhaps a paper)
| about the way FireBird stores data? This may sound a bit vast, but what
| I'm interested in specifically, is understanding how, when an update is
| performed, it is written to the database, and how exactly the
| multigenerationnal system works. If I perform a select, how does
| Interbase know which version of the record to show me, etc?
|
| The reason I would like to understand this more fully, is because I'm
| wondering how it would be possible to make FireBird 100%
| corruption-proof. In other words, how can we make every single disk
| operation atomic? Naturally, there is already a degree of atomicity due
| to the transaction system, but what would be good, would be to make
| every single write atomic; that is, if it gets cut off in the middle,
| have some flag somewhere, or something that can tell us that the write
| wasn't completed, and that it can therefore be treated as though nothing
| had happened at all.
|
| For instance, if I perform several inserts into a table of my database,
| within the scope of my transaction, these inserts are atomically grouped
| together, and I either commit them all, or roll them all back.
| Therefore, if the client disconnects abruptly after the first insert,
| everything will get neatly rolled back. However, if, during one of the
| inserts, there's a power failure, the record will only partially be
| written to disk, resulting in an incorrect structure, worse than if
| nothing had been written at all. We need to have a way of telling that a
| certain operation was not completed successfully, and can therefore be
| discarded.
|
| Of course, I also know that there is an option called ForcedWrites,
| which, if it is used (which of course, it is on all my databases), makes
| the database perform synchronous writes instead of asynchronous writes.
| This helps a lot of course, because it greatly reduces the likelyhood of
| there being unwritten data pending in the event of an abrupt shutdown.
| However, it's not good enough in many cases. It's still theoretically
| possible to have corruption due to a power failure. Also, a badly coded
| SP of trigger can make the database to loop indefinately. In such an
| event (I've had this happen to me), the only solution is to kill the
| server process (killing the client isn't enough). If the SP was
| performing database writes, and not mere reads, it's very likely to
| corrupt the database, for obvious reasons (this is what happened in my
| case). And of course, there are other ways of corruption a DB as well.
|
| Do you think it would be possible to design the system in such a way
| that every write is entirely atomic? And if so, would this entirely
| solve the problem, or am I missing something. It seems to me that in
| such a case, we could even afford to turn ForcedWrites off, without it
| affecting the stability of the database at all. Unfortunately however,
| my current understanding of the internal structure of the database is
| too limited to enable me to seriously speculate in this area...
|
| Any ideas?
|
| Jonathan Neve.
|
|
|
|
|
| Yahoo! Groups Links
|
|
|
|
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)

iD8DBQFAaw4nvWeCZ4RLdzYRAuJbAJ9BkhAhxLK88Wei+KyIlvCrDMnx7QCcDxwj
MLNlSefchBRP9KSF9KhsNe0=
=FHgT
-----END PGP SIGNATURE-----