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 understand).
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... -- Maciej Wisniowski _______________________________________________ Zope-DB mailing list [email protected] http://mail.zope.org/mailman/listinfo/zope-db
