[ZODB-Dev] ConflictErrors that keep coming up

Tim Peters tim at zope.com
Thu Mar 17 11:04:28 EST 2005


[Florent Guillaume]
> You have to call _p_jar.sync() (sync the connection) between transactions
> before restarting, to see changes made by other connection.
>
> I had to do this explicitely when moving from Zope 2.6 to 2.7 for a
> customer; apparently this used to be automatic when new transactions
> started in Zope 2.6, but not anymore.

Hmm.  Something's fishy about that.  Because of the way ZODBs before 3.3
work, the transaction machinery never learned about a Connection unless an
object loaded from that Connection was modified during the transaction, so
it was always necessary to sync() Connections from which objects were only
read (well, "necessary" if and only if you _wanted_ to get current data from
them, and/or boot old objects out of their memory caches).  The flip side is
that it should never have been necessary to sync() a Connection if an object
from that Connection was modified before a commit() or abort().

It could be that something obscure changed in Zope, but the story in
ZODB/ZEO has been consistent this way (AFAIK) "forever", until ZODB 3.3
(which has a different approach -- see the thread I pointed Chris at in
earlier email).  There were also bugs in non-current ZODBs in the 3.2 line
wherein transaction().begin() sometimes failed to realize that changes in
subtransactions were still pending, and so failed to abort those changes;
that could also lead to the incorrect _appearance_ of needing to do a sync()
(the first thing sync() does under the covers is an explicit transaction
abort(), so it's possible that a user-coded sync() covered up a ZODB bug in
begin() semantics).



More information about the ZODB-Dev mailing list