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 _______________________________________________ Zope-Dev maillist - [email protected] 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 )
