[ZODB-Dev] ZODB _v_ attributes are tricky

[Kapil Thangavelu]

On Fri, 2004-04-02 at 18:53, Dieter Maurer wrote:
> Shane Hathaway wrote at 2004-4-2 11:48 -0500:
> > ...
> >Instead, ZODB ought 
> >to provide two kinds of documented descriptors: Volatile and 
> >TransactionalVolatile.  Volatile attributes revert to the default state 
> >at any time; TransactionalVolatile attributes reliably revert to the 
> >default state upon commit or rollback (including savepoint commit or 
> >rollback).
> 
> I fear, we need more kinds:
> 

i agree with your assessment completely.

>   1. attributes that can disappear at any time
> 
>      used for caching
> 

the current model

> 
>   2. attributes that can disappear only at main transaction boundaries
>      (but are not garanteed to disappear at the next boundary)
> 
>      used for caching of objects that are transactional aware
>      such as database connections

yes, this imo, is a major problem with in process external integration
of resources in zope at the moment, namely that under high load their
behavior is less than ideal and requires lots of special consideration. 
perhaps either not ghosting the persistent object with such attributes,
or having attributes on ghosts.

> 
>   
>   3. attributes that are garanteed to disappear at the next
>      transaction boundary (do we need to control which
>      type of transaction boundary?)
> 
>      do we need this type? for what use case?
>
> 
>   4. attributes that live precisely for the current request
> 
>      used for things like "_v_skininfo".

i think 3 and 4 are similiar enough that they can be merged into one, ie
a transactional attribute, some computation, as zodb is not request
bound, ie has no notion of such, it would be better imo to tie it in at
the transaction level.

so CachedAttribute with current volatile semantics,
TransactionalAttribute for transaction lifecycle semantics, and
ResourceAttribute (?) for txn aware resources with undefined lifetimes
but well defined lifecycle.

-kapil