[ZODB-Dev] ZODB _v_ attributes are tricky

[Dieter Maurer]

Tim Peters wrote at 2004-4-2 11:28 -0500:
>[Shane Hathaway]
>>> ZODB destroys volatile attributes only when
>>> unloading objects.  ZODB unloads objects after another connection
>>> changes them.  Also, the ZODB garbage collector unloads objects at
>>> the end of transactions.
>
>[Toby Dickenson]
>> The garbage collector can also be triggered explicitly by application
>> code, and future improvements to the garbage collector might unload
>> objects at other times too. In short, you should assume that _v_
>> variables might disappear at any time.
>
>Part of the problem I perceive (and correct me if I'm wrong) is that the
>docs are so lacking now that very few people are able to distinguish
>accidental behavior from "officially supported" behavior.

"_v_" attributes are (mostly) an implementation artefact.
They disappear whenever the containing object is flushed ("invalidated")
from the ZODB cache.

Currently, the ZODB code flushes objects from cache only at
transaction (main or sub transaction) boundaries.
The application is however free to call "invalidate" explicitely
(which usually flushes the object, but sometimes does not);
it can also do "obj._p_changed = None" which flushes the object
indisciminantly -- at the full risk of the application.

Many "_v_" attributes uses *REQUIRE* that the variable is
lost only at main transaction boundaries. Most prominent
example: the database connections maintained by Zope's
standard database adapters. Another example: the "_v_skininfo" (or similar)
used by the "SkinsTool".
These uses can break with the current ZODB implementation
(when subtransactions are used).
I posted a patch to "zodb-dev" to prevent invalidation
at sub-transaction boundaries.


Thus, we have the case, that nothing specifies the precise
rules when the ZODB flushes objects.
Several standard Zope products rely on the fact that
objects are only flushed at main transaction boundaries.
The current ZODB implementation flushes at main and sub transaction
boundaries (and breaks those standard Zope products).

-- 
Dieter