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
--
Jim Fulton
Zope Corporation
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
