On Jan 13, 2008, at 7:49 AM, Dieter Maurer wrote:

Jim Fulton wrote at 2008-1-11 18:20 -0500:
BTW, in situations in which you don't know which objects to
deactivate, an alternative is to call cacheGC on the connection
frequently.  This is fairly inexpensive and incremental.

But, it can kill volatile variables as well -- which may
lead to trouble, until we have implemented something like
"Garanteed lifetime for volatile variables".

Current potential trouble includes:

 *  inconsistent transactions in relational databases
    (as "_v_" variables are used to hold the database connection)

This is an interesting case.

 *  broken Archetypes copy/move code
    (as "_v_" variables are used to communicate with
    'manage_afterAdd/beforeDelete further down the tree)

Perhaps volatile variables are a bad idea. They enable many subtle errors. OTOH, I fear that without them, people would resort to other tricks that might be even worse.

What sort of lifetime would you consider appropriate for volatile variables? You example above suggests that they should stick around until a transaction boundary (not including savepoints). I wonder if there are other examples that might want something else.

Or perhaps people should take the name "volatile" more seriously.


Jim Fulton
Zope Corporation

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to