From: Clifford Heath <no@...>
Date: 2008-09-26T21:34:41+09:00
Subject: Re: How to make Ruby _THE_ scripting language of choice, fold in SQLite

David Masover wrote:
>> Nevertheless, though this method can solve the (D)urability problem of
>> ACID, it offers no solution to A, C, or I, so is still not transactional.

I might be labouring a point here, and I really don't mean to
give you a hard time. However, perhaps I can clarify further...

Most or all transactional systems rely on the ability to perform
some finite-sized atomic operation on persistent storage. By finite
size, I mean more than just flipping a single bit. Often it's
expected that if a disk block is written, the whole block is written.
Some systems put a LSN on the start and end of the block, and if
they're both intact on read, they assume that all the stuff in
between got written too. If you have the memory bandwidth for it,
you can also use "torn page detection", where the contents is
checksummed and written in a header, which does check every bit
to whatever level of confidence your checksum warrants.

This ability to perform single operations with ACID semantics is
assumed - because without it we can't do any more - and hence
isn't interesting. If the chunk you choose is a whole file, it
still isn't interesting, because it's still all or nothing on a
single object. No-one rewrites an entire database to save one
record.

The interesting cases arise when you must coordinate updates to
more than one such object. It's *then* that isolation, consistency
and atomicity actually seriously mean something.

The examples you gave do not provide a use case where all 4 ACID
properties are supported in such multi-atom situations - they only
support or require some subset. There are interesting applications
that can live with such less-than-transactional behaviour, but
don't confuse those implementations with databases. They're useful,
but they're not transactional in any non-trivial sense.

Clifford Heath.