Jim Fulton wrote at 2008-1-13 10:40 -0500:
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).
You know, there is a proposal from me about "Garanteed lifetime for volatile variables" in the ZODB wiki for months -- and we (in our private copy) use the corresponding implementation for years (and this implementation was also committed to the Zope bugtracker for years).
I wonder if there are other examples that might want something else.
I think that 2 lifetimes are sufficient: * can disappear at any time * lives at least until the (full) transaction boundary
Or perhaps people should take the name "volatile" more seriously.
Then the legitimate use cases for attributes that are not arbitrarily volatile (detailed in my proposal) will need a different solution -- *AND* at least the Zope code for database adapters must use this new solution. -- Dieter