On Jan 17, 2008, at 4:05 AM, Christian Theune wrote:


tpc_finish has a callback function that is passed in and should be called before releasing the commit lock. (This is documented in BaseStorage, but the interface for tpc_finish does not talk about the argument.)

No, the storage lock, not the commit lock.

The requirement here is not clearly stated and should not be stated in terms of the storage implementation. I need to think of a better way to express it. The basic idea is that no reads should be performed between the time the transaction is committed by the storage and the time the invalidations have been communicated to the database. Otherwise, a connection might read data committed by T without seeing the the corresponding invalidations, leading to inconsistent data.

Comparing ClientStorage and BaseStorage we found that:

- ClientStorage performs the callback _after_ calling tpc_finish on the
- BaseStorage performs the callback _before_ calling _finish on the
 actual implementation.

We have the feeling that we either miss the point or one of those cases is wrong.

You miss the point.

Can someone shed some light on this?

The order that the underling finish is performed and the callback is called isn't important. It is only important that no loads should be allowed before those times.

The ordering requirements need to be specified more clearly, without relying on an implementation detail, like a lock. In fact, requiring the lock to be held is overly restrictive. For example, it would be fine, for example , to allow loadBefore or loadSerial calls.

I will try to come up with a better specification.


Jim Fulton
Zope Corporation

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to