[Persistence-sig] Clearing participants (was Observation API)

[Phillip J. Eby]

At 01:35 AM 7/31/02 +0200, Sebastien Bigaret wrote:

>Phillip> * The need for participants to join every transaction.  This
>Phillip> is one of my top complaints about the existing API.  I have
>Phillip> *never* had a single application where I couldn't simply
>Phillip> register all participants to the transactions at or near
>Phillip> startup, and never need to do so again -- if it weren't for
>Phillip> the fact that the transaction API doesn't work that way.  I
>Phillip> have to write code that tracks whether an object has been
>Phillip> registered with *this* transaction, and knows when the
>Phillip> transaction is over so that it knows it needs to register
>Phillip> again
>
>   ...I can't decide whether you are talking about initialization of a
>   transaction _instance_. The last sentence suggests that participants
>   are unregistered when the transaction closes: do you mean destroyed,
>   or commit/rollback time? If this is the latter case, then I guess I
>   have missed something, since I cannot find any references in the
>   previous threads about participants being unregistered at that
>   point. If this is the first case (hence, making it possible to
>   generate a given set of DataManagers for each new transaction), then
>   my proposal for DM-factories might be meaningful.

Sorry, the "transaction API" and "existing API" I referred to is the 
currently available transaction API in Zope/ZODB, not the API I proposed on 
this list.  The old Zope/ZODB transaction API requires registration for 
each transaction lifecycle; the registration list is cleared upon every 
commit or rollback.

My motivation for making registration permanent in my "Straw Man" 
transaction API proposal was to counteract this.  In the API Shane and I 
are discussing, there would be an option to register with a transaction 
instance such that the registration would remain across commit/rollback 
boundaries.