[Dev] transactions per second

David McCusker david at treedragon.com
Mon Nov 11 15:03:24 PST 2002


Jeremy Hylton wrote:
> A ZODB transaction with FileStorage calls flush() before reporting
> that a transaction has committed. 

Which moves the buffering from the app to the operating system, and
doesn't guarantee content is on disk.  I know you know this, so this
is for other readers.

 > That's the durability guarantee you get.

When FileStorage works by appending, and the transactions are marked
so the starts and ends are findable, this is an adequate amount of
durability since one can ignore incomplete transactions.  (Incidentally,
this is exactly how I had the Mork text db format work for Netscape.)

> There's only one kind of transaction in ZODB, and it has the
> standard ACID properties.  

If D stands for durability, and flush() is not durable, then why do
you say ACID when the D is not supported?  (Just curious.  It takes
me a while to calibrate other folks' standards.)

> I suppose we could consider more flexibility in ZODB4, although
 > I'm not sure that it would rank high on the priority list.

I was thinking of variety in Chandler transactions, under the theory
they were not necessarily identical to ZODB transactions.

--David McCusker





More information about the Dev mailing list