[ZODB-Dev] [Problem] "_v_" variables too volatile

[Jeremy Hylton]

On Wed, 2003-12-10 at 06:32, Dieter Maurer wrote:
> The ZODB flushes its cache only at transaction boundaries.
> Therefore, "_v_" attributes behave usually for the use cases above.
> If however, subtransactions are used, these use cases can break
> non-deterministically.

Perhaps the solution should be sub-transaction specific, since that's
the source of the problem.  Then you wouldn't need to pay for this
feature for the vast majority of objects and transactions where
subtransactions aren't used.  I'm thinking about the cost (space and
speed) of adding extra magic for _v_ variables.

> There are two options:
> 
>   *  abandon "_v_" variables for such use cases
> 
>      We then need a new device for these use cases

Just to be clear: The use cases is to avoid storing some attributes in
the database record.  They take advantage of _v_ variables to avoid
writing an __getstate__ for the object.

>   *  prevent objects with "_v_" variables from being flushed
>      at subtransaction boundaries

> Unless I do not here strong objections, I will extend
> the ZODB such that:
> 
>   *  setting a "_v_" attribute of a "Persistent" object
>      sets a "_p_volatile" attribute.

How would you implement this attribute?  I'd prefer to see a single bit
put in the object header.  Note that objects can already be in the
sticky state.  C code sets the sticky state when it stores a pointer to
the object; the cache will not evict an object in the sticky state.

Perhaps this new mechanism can just piggy-back on the sticky state,
although that adds some complexity for modifications.  That is, if the
object is marked as sticky before it's changed, I'm not sure if the
change notification is made correctly.  If it isn't maybe sticky needs
to be revised to serve both purposes.

>   *  "incrGC" gets an argument "flushVolatile", defaulting to "1".
>      If not set, objects with "_p_volatile" are not flushed
> 
>   *  in "subtransaction commit/abort" "incrGC" is called
>      with "flushVolatile=0".

We can use True and False now, as Steve noted.  But if the state was
managed using the sticky feature, there would be no need for an explicit
flag.  The chief downside is that a programming error could leave an
object in the sticky state and, thus, forever in the cache.

Jeremy