[TransWarp] Re: [ZODB-Dev] SQL/ZODB integration (was Re: ZODB and new styleclasses?)

[Jim Fulton]

Phillip J. Eby wrote:
...
> Side note: ZODB transactions aren't necessarily 100% serializable in any
> event; it's not enough to check that something you changed wasn't changed
> by someone else.  Technically, anything you *access* in the current
> transaction that was read in during a previous transaction, but whose saved
> state changed in the meantime, results in an inconsistent transaction if
> you used that information to decide what to write!

That's not quite right. You can read old data as long as it is consistent.

> Unfortunately, there is not a good mechanism in the current ZODB
> architecture to allow detecting this condition, as there is no list of
> "objects accessed but not loaded in this transaction" nor a way to generate
> one.

I think you are mistaken. :)

At the start of a transaction, any objects that have been modified since they were
last read are deactivated.  All data in the cache are consistent and reasonably
up to date as of the start of the transaction.  During the transaction, any attempt
to read data written since the start of the transaction will cause the transaction to
abort. This is serializable behavior.

An extreme case is a transaction that reads two values, A and B, and stores the
sum of them in a third value, C. Imagine that the transaction reads A and B. Then
another transaction modifies and commits changes to A and or B.  Then the first
transaction computes and commits C. The committed value of C will not be the sum of
the committed values of A and B. But the transactions are serializable. They can
be serialized by ordering the first transaction before the second, even though the
second transaction committed first.  The fact that C is not the sum of A and B is
a result of poor application design, not due to a flaw in the transaction machinery.

Note that we plan a major performance improvement that will cause transactions to read
data committed as of the transaction start time even if newer data has been committed.
This will assure consistency and serializability without producing as many conflicts.

(There are some edge cases in the current implementation that should be fixed.
  For example, invalidations are processed one by one. All of the invalidations
  produced by a transaction should be processed at once. This flaw can readily
  be fixed, when time allows. Volunteers? ;)

Jim

-- 
--
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org