Chris Withers wrote:
Casey Duncan wrote:
I would argue that a better plan would be to only use _v_ vars for completely disposable data only. The application should expect that this values will be gone at any random time, not just at transaction boundaries.
Agreed. Are there any situations, apart from the already discussed CMF skindata, where this currently isn't the case?
I'm a bit puzzled - of what use is a variable which may disappear "at any random time"?
It's not exactly random. It would happen when the object was deactivated (removed from cache). If the object is marked as changed (ala _p_changed=1) then its __getstate__ will be called before it is deactivated. If it hasn't changed though then it doesn't really get a chance to do anything about it.
Deactivation only happens AFAIK at transaction or subtransaction boundaries. This gives at least some predictability, since subtransactions are rarely used. Perhaps this is why database adapters have been historically incompatible with subtransactions?
It seems to me that DAs are a bit broken with regard to where they store their database connection objects. They should register an object with the transaction that holds the connection so that it can be properly committed or aborted regardless of what happens with _v_ variables in the interim.
-Casey
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
