On Jan 17, 2008, at 4:05 AM, Christian Theune wrote:
Hey,
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
server
- 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
--
Jim Fulton
Zope Corporation
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev