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

[Phillip J. Eby]

At 10:48 AM 7/2/02 -0400, Jim Fulton wrote:
>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.

It's pretty common, in my experience, for an application to use data from
one place to make a decision regarding data in another place.  When I said
ZODB transactions, I didn't mean in the sense of ZODB as a whole, but
specifically regarding the transaction and persistence parts.  ZODB, in the
common usage, is fine in this area because it has central invalidation at
minimum, and asynchronous invalidation via ZEO.  I was speaking of using
the packages which aren't part of "ZODB" to do persistence on non-ZODB
backends, if that made any sense.


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

I think I mis-spoke again, or to be precise, omitted something.  :)
Specifically, that I meant there was not a good mechanism in the
architecture for detecting that condition *when using back-ends that don't
push notification of changes*.  Such as an RDBMS, for example.


>At the start of a transaction, any objects that have been modified since
they were
>last read are deactivated.

Right, and not all back-ends provide any kind of notification that lets you
do this.  I suppose you could reasonably consider this a deficiency of the
back-ends rather than of the ZODB framework.  :)  But it's nonetheless a
requirement for many people to use such back-ends.  :)


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

Eeek!  I can see this for CMS applications, but some applications really
*need* pessimistic conflict detection, i.e. locking.

One thing that's illustrated very well by this little interchange is the
need for a clear taxonomy and common working terminology in the new SIG,
right from the start.  :)