[Persistence-sig] A simple Observation API

[Shane Hathaway]

On 31 Jul 2002, Sebastien Bigaret wrote:

>   ...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.

The terminology we're using is a little confusing, since an object that is
truly a transaction should probably begin its life at the beginning of a
transaction and, at commit or rollback time, should become permanently
immutable.  It might even be stored in the database.

But the things we've been calling transactions play a role more like
transaction "coordinators".  As coordinators, they might be reused for
numerous non-overlapping transactions.  If they are reused, it makes
sense to be able to register a permanent transaction participant with a
specific coordinator.

I think there might a problem, though.  ZODB customarily uses one
transaction coordinator per thread.  But ZODB connections are not really
thread-specific; they may be reused in a different thread when they are
opened or closed.  So if, for example, you registered a permanent
transaction participant that cleared the cache of a specific ZODB
connection, you wouldn't get the effect you wanted! :-)

That's why I suggested that if you want permanent participants, that
perhaps you'd really want to register the transaction participant for all
threads.  It requires you to consider thread safety, but I think you'd
frequently have to consider that anyway.

Shane