[ZODB-Dev] Objects ghostified during a transaction

[Tim Peters]

[Florent Guillaume]
> I'm confronted to a bug in CMF (http://zope.org/Collectors/CMF/198) where
> a _v_ variable disappears in the middle of a request (and reverts to its
> class-default of None).
>
> I want to fix this by removing the reliance on _v_ variable, but to write
> a unit test for it I'd like to be sure of why it happens. Can an object
> be deactivated *in the middle* of a transaction? As a datapoint, it's
> quite likely that some partial transactions (get_transaction().commit(1))
> occur when the bug appears.

The official story is that you cannot rely on a _v_ attribute surviving
across any operation:

    http://zope.org/Wikis/ZODB/VolatileAttributes

If you think you detect patterns beyond that, you're relying on coincidence
or implementation accidents, and they may change at any time.

Of course in any specific release of ZODB, there are definite times at which
_v_ attributes can, and cannot, vanish.  Trying to detail those would be an
excerise in undocumented futility, though.  As a matter of accident, it so
happens that they *probably* won't vanish except at transaction boundaries
(whether subtransaction or top-level).  That's not really anyone's intent,
though, it's primarily that a transaction commit calls
Connection._flush_invalidations(), which happens to have this code today:

        # Now is a good time to collect some garbage
        self._cache.incrgc()

Then, in turn, if cache gc happens to ghostify an object that happens to
have a _v_ attribute, then that _v_ attribute will go away.  You can
maximize the likelihood of _v_'s vanishing by configuring the cache to hold
very few objects, or make it less likely by increasing the cache size.

IOW, it's accidents piled on accidents piled on accidents.  That's why the
official story is that you can never rely on a _v_ sticking around -- nor
can you rely on a _v_ going away!  Of course "volatile" implies all of that,
so nothing about this is surprising <wink>.