[Persistence-sig] A simple Observation API

[Jim Fulton]

Shane Hathaway wrote:
> 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,

This doesn't help. ;)

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

Right. We really need to clean up the terminology. We should distinguish
between "transaction coordinators" (or "transaction managers" or whatever)
and transactions.

> I think there might a problem, though.  ZODB customarily uses one
> transaction coordinator per thread. 

This is changing. In the future, you'll be able to asociate a connection
and a transaction coordinator independent of 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! :-)

But ZODB connections are rarely used by multiple threads at the same time.
In the model where you do associate transaction coordinators with threads,
what you'd want to do is register a connection with a thread-global
transaction coordinator when the connection is opened and unregister it
when it is closed.


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

No, you don't want that.

 > It requires you to consider thread safety, but I think you'd
> frequently have to consider that anyway.

No, with ZODB you effectively never have to worry about threads.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org