If these conditions are met, you will lose your connection. Still
nothing bad happens as the transaction still holds a reference to it
and may eventually commit/abort it at transaction end time.
And as they are very rare and apparently non-deterministic,
they are almost impossible to analyse (and quite difficult to
Thanks! I think, I have no such conditions met in my apps, ufff... :)
This might be possible but need not be a problem:
The order in which operations occur at commit time can be controlled
via the resource manager's "sortKey" (or similarly spelled).
I've seen that but was not sure what value is returned
by ZODB resources in sortKey. Possibly it's easy to check this.
In this case, you may see the loss of the "_v_" variable
(caused either by the cache garbage collection or the invalidation
of the DA object) before the relational "abort".
I don't know how abort of ZODB resource managers works but
doesn't rollback of ZODB resource manager remove _v_ variables?
or.. maybe it causes cache garbage collection or invalidation?
However, the transaction holds an additional (beside the "_v_" attribute)
reference to the connection and can commit/abort it despite
the loss of the "_v_" attribute.
How can I get access to this? _v_db in Procedure class in
SP.py of DCOracle2 disappeared in my case...
Zope-DB mailing list