[ZCM] [ZC] 1596/ 4 Comment "ZODB: more control over object deactivations "

[Collector: Zope Bugs, Features, and Patches ...]

Issue #1596 Update (Comment) "ZODB: more control over object deactivations "
 Status Pending, Database/feature+solution medium
To followup, visit:
  http://collector.zope.org/Zope/1596

==============================================================
= Comment - Entry #4 by ajung on Nov 25, 2004 2:59 pm

Any volunteers to clean the patch for 2.8/2.7?
________________________________________
= Comment - Entry #3 by d.maurer on Nov 25, 2004 2:56 pm

The patch is already quite old.
Meanwhile, Tim took over ZODB maintenance any probably has cleaned up some parts. I expect that minor parts would need adjustment.

For Zope 3.3, I know from messages in zodb-dev, that some adjustments will be necessary as Tim removed e.g. "_ingrgc".

________________________________________
= Comment - Entry #2 by efge on Nov 24, 2004 5:58 pm

Thanks Dieter.
I'd like to apply this patch quickly (I'd rather Tim did it though :))
Is it acceptable on the 2.7 branch ?
Would it need modifications on ZODB 3.3 for Zope 2.8 ?


________________________________________
= Request - Entry #1 by d.maurer on Nov 24, 2004 3:12 pm


Uploaded:  "zodb_sticky.pat"
 - http://collector.zope.org/Zope/1596/zodb_sticky.pat/view
Several parts of Zope use volatile variables ("_v_")
which must not disappear during a transaction.
Most prominent examples are Zope's database adapters
that use a volatile attribute to hold the connection
to the database.

The current ZODB implementation can deactivate objects
at sub-transactions and transaction boundaries.
Deactivating objects with "_v_" attributes at subtransaction
boundaries, can seriously affect transaction consistency
(when a connection in a Zope database adapter is dropped).

This has beend discussed on zodb-dev in Dec. 2003. Most
people favoured a way to control object deactivation during
a transaction.

On Feb. 7th, 2004, I posted the attached patch to zodb-dev
with the following description. It allows to easily fix
problems with premature loss of "_v_" variables.


Quote from a "zodb-dev" post from Feb 7th, 2004, titled:
More "cPickleCache.incrgc" control
  (was: [Problem] "_v_" variables too volatile)

The attached patch against the Zope-Head CVS version
of 2004-02-07 provides more control as follows:

  *  Persistent objects get a new "_p_sticky" attribute which
     can be read and written (from Python).

     It is a boolean, but currently implemented (in "C") as a byte
     (just because byte access is more efficient than bit access).

     The "Sticky" state could not be used for this purpose
     as it is reset at transaction boundaries while
     our "_p_sticky" must remain until object deactivation

  *  "cPickleCache.incrgc" already had an ignored optional
     argument.
     This optional argument now gets the interpretation
     "mayFlushSticky" (and is no longer ignored).
     Its default is "True".

     If true, "incrgc" is allowed to deactivate objects
     with a true "_p_sticky". Otherwise, it must not deactivate
     such objects.

  *  "ZODB.Connection" is changed such that it calls "cPickleCache.incrgc"
     with "mayFlushSticky" true only in
     "setDB", "sync" and at boundaries of main transactions (and
     not subtransactions).

     As subtransaction handling is a bit convoluted :-(
     "incrgc" may be called with "mayFlushSticky=False"
     even when a main transaction is aborted (as it is not
     always clear whether a main or a subtransaction is aborted).

  *  "minimize" never flushes objects with "_p_sticky == True",
     as it is usually called asynchronously.


The patch does not automatically prevent "_v_" attribute flushing at
subtransaction boundaries. Only if "_p_sticky" is explicitely set to a true
value, a flush at subtransaction boundaries is prevented.

A "self->sticky = 1" in the "_v_" attribute handling
of "cPersistence:Per_setattro" 
would make "_v_" protection automatic but
most discussion contributors said "explicit is better than implicit"
and saw use cases where "_v_" variables need no protection.

==============================================================