Transactional Code Completed! 0.92.6+txn2.0 released

[Matthias Andree]

On Wed, 01 Sep 2004, Tom Anderson wrote:

> Power out?  UPS.  Generator.  What are hosting facilities for, after all?
> But, anyway, isn't this considered a hardware failure?  A power failure
> would seem to be worse than any other kind of hardware failure.

UPS/generator/whatever are no silver bullets.
The computer's PSU can fail. The onboard DC-DC converter for the CPU can
fail. The CPU can fail.

> Kernel crash?  That hasn't happened in a long, long, long, long time.

OK.

> But what if my RAM goes bad... that happens fairly often (every year or two
> on at least one of my machines)... or bad sectors on my harddrive... all too
> often... or an over-heated case... happened on occasion...  That's my
> question.  Matthias qualifed the usefulness of the transactional code with
> the assumption that your "hardware works well".  What if it doesn't?  I just
> want more specifics on what hardware needs to work well and what constitutes
> working well.

Of utmost importance is that
1. failure modes be reported and
2. serialized operations aren't re-ordered (which implies that
synchronous I/O operations are on stable storage before the "complete"
reply reaches the DB library or bogofilter application).

Everything that just stops operation without modifying the data or order
is fine, the TXN code can then rollback and undo the uncommitted
changes and redo the committed changes. If your disk drive suffers
catastrophic failure all of a sudden, you may be left with what is in
your last backup.

So, make sure that your hardware detects a RAM fault and halts the
machine before it can write junk to the disk. This usually implies some
ECC RAM with ECC detectors that can generate an NMI to halt the machine,
possibly with software that logs correctable faults so you know ahead of
time something's coming your way.

> In what scenario is the transactional code not going to be rock solid?

I need to refer you to the Berkeley DB documentation for that is all I
know myself about recoverability in Berkeley DB:

http://www.sleepycat.com/docs/ref/transapp/reclimit.html

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)