Re: Zope database connectivity

>  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