[Persistence-sig] A simple Observation API

[Phillip J. Eby]

At 10:26 PM 7/30/02 -0400, Shane Hathaway wrote:

>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! :-)

Well, ZODB could always:

1. do as it does now, and register non-permananently, or
2. pool the transaction with the connection. (See below.)


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

In my use case, the transaction will live as an attribute of a root 
"application" object, and application objects will be pooled for use by 
different threads.  Application objects also contain as attributes all 
their connections, data managers, etc.  So everything's pooled together, 
and there's no question of which transaction goes with what.

This approach is virtually identical to what Zope does now, except that 
Zope keeps the transaction with the thread, instead of with the resource pool.