[ZODB-Dev] Re: [Zope3-dev] revise transaction API

[Jim Fulton]

Jeremy Hylton wrote:
> On Tue, 2004-03-30 at 15:39, Jim Fulton wrote:
> 

...

>>What about a model where there was a TM per thread.  Then, the methods
>>above would get the calling thread's TM and delegate to it.
>>Similarly, one could create a new TM and use it to manage changes
>>independent of thread perhaps.
> 
> 
> I think I follow the end goal, but not the mechanism you propose.  If we
> had a TM per thread, it seems like it would be harder to implement a
> policy of one transaction independent of threads.

No.  One could, presumably instantiate their own TM independent of
threads.  They could use it it create transactions that are thread
independent.

So my suggestion is to have a simple TM implementation that is thread
idependent.  This would be in a separate module of it's own.

Then implement the thread-global-transaction model using this TM.
Provide conventience functions as you proposed that manage TMs, rather
than transactions by thread.

> The current proposal would allow the application to change policy by
> installing a new transaction manager.  The simplest transaction manager
> would just have a single "current" transaction that was independent of
> thread.  I imagine we'd implement that so that we could use it in
> conjunction with db.open().

I'd hope so.

> 
>> > The individual transaction objects should have a register() method
>> > that is used by a resource manager to register that it has
>> > modifications for this transaction.  It's part of the basic API, but
>> > not the basic user API.
>>
>>We had use cases for allowing resource managers to be able to register
>>with transaction managers, to be notified of transaction-relevent
>>events.  I think that this was important for MVCC to be able to
>>invalidate historical objects at the end of read transactions.
> 
> 
> There's a separate section on registration and notification.  It
> suggests having a different set of registrations for synchronization. 
> I've implemented that by allowing a Connection to register itself with a
> TM; 

With the TM? or the T? :)  You haven't provided an API for getting the TM,
so I assume you mean the T.


> the Connection provides beforeCompletion() and afterCompletion()
> callbacks that are called before and after a commit or abort.

OK

> 
>> > Extended transaction API
>> > ------------------------
>> >
>> > There are a few other methods that might make sense on a transaction:
>> >
>> > status() -- return a code or string indicating what state the
>> > transaction is in -- begin, aborted, committed, etc.
>> >
>> > note() -- add metadata to txn
>> >
>> > The transaction module should have a mechanism for installing a new
>> > transaction manager.
>>
>>We also need the ability to store application-defined data.
> 
> 
> Right.  In the working implementation, we've still got the _extension
> code from current ZODB.  Is that code used anywhere?

It is or will be in Z3.

Are you getting rid of "user"?  If so, then we need to
put it in the extension data.

We also need to provide backward compatible (though deprecated) APIs.


> 
>> > ZODB Connection and Transactions
>> > --------------------------------
>> >
>> > The Connection has three interactions with a transaction manager.
>> > First, it registers itself with the transaction manager for
>> > synchronization messages.  Second, it registers with the current
>> > transaction the first time an object is modified in that transaction.
>> > Third, there is an option to explicitly pass a transaction manager to
>> > the connection constructor via DB.open(); the connection always uses
>> > this transaction manager, regardless of the default manager.
>>
>>Is this a transaction manager, or a transaction?
> 
> 
> That's a transaction manager.  A transaction only lasts from a begin to
> a commit.  Would it be useful to have a connection only be allowed to
> participate in a single transaction?

Right, so as I mentioned above, it's unclear where the connection gets the TM.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org