From: David Masover <ninja@...>
Date: 2008-09-26T15:20:02+09:00
Subject: Re: How to make Ruby _THE_ scripting language of choice, fold in SQLite

On Friday 26 September 2008 00:09:50 Clifford Heath wrote:

> However, without the fsync, its still not transactional, as you can pull
> the power cord after the operation and there's no guarantee that the disk
> blocks that make up the file content are actually on disk. All the FS
> journalling does is to ensure that the block allocation tables and inodes
> are clean.

Unless you've got data journaling and ordered writes.
I mentioned the ordered writes; I forgot to mention the data journaling.


> 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.

Definitions paraphrased from Wikipedia:

(A)tomicity: Either all of the tasks are performed or none of them are.

In this case, I'm assuming that the temp directory is regularly cleaned, often 
on boot. But I'm not sure that's relevant -- extra tempfiles waste space, but 
they don't constitute a half-finished transaction, if the actual _data_ being 
operated on is the target file/directory.

Counting a dangling tempfile as a point against atomicity is a bit like 
counting an unfinished journal (which must be replayed and likely rolled 
back) the same way.


(C)onsistency: the database remains in a consistent state after the 
transaction is over (whether successful or not).

Since only completely-flushed (fsynced) files are renamed, assuming rename is 
atomic, the directory in question will always be consistent -- you'll never 
have half an email actually committed in maildir.

Again, I'm not counting a dangling tempfile towards consistency any more than 
I would count a dirty journal which must be played back / cleaned up after.


(I)solation: other operations cannot see or access the data in an intermediate 
state during the transaction.

Granted, if you really wanted to, you could access anothers' tempfile -- but 
then, if you really wanted to, you could read the database/filesystem's 
journal. But this would have to be deliberate -- it is not difficult to 
generate unique tempfile names, without knowledge of what other processes are 
doing. (See Maildir.)


I realize it's an ugly, brutal hack, and I realize it's ancient. I wanted to 
demonstrate that relational databases do not have a monopoly on transactional 
properties -- not only that, such transactions are not actually all that 
difficult to get right.


> Neither is Amazon's approach, and neither is DVCS, despite their success
> in solving *different* problems.

I'm up too late to try to figure out what you mean here.
It's entirely possible I'm wrong.

I suspect a more rigorous definition is in order, though. After all, from 
Wikipedia, Durability implies:

"once the user has been notified of success, the transaction will persist, and 
not be undone."

DVCS and Amazon both allow for such transactions to be "undone", in a sense, 
by further changes overwriting the result of the transaction. But the 
transaction itself is never forgotten.