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

Jim Fulton jim at zope.com
Tue Mar 30 15:39:43 EST 2004


I'm removing zope3-dev from the CC

Jeremy Hylton wrote:
> We've been having some internal discussions about how to revise the
> transaction API for ZODB 3.3.  I posted a page in the ZODB Wiki that
> summarizes the issues we're working on and suggests a plan of action --

I didn't see the plan of action.

> a minimal set of changes that could make it into 3.3.  Comments are
> welcome.
> 
> http://zope.org/Wikis/ZODB/ReviseTransactionAPI

Here are some comments:



 > 4. Transaction Manager -- coordinates the use of transaction.  The
 > transaction manager provides policies for associating resource
 > managers with specific transactions.  The question "What is the
 > current transaction?" is answered by the transaction manager.

I guess "current" has to be interpreted wrt the transaction manager.

...

 > Current transaction
 > -------------------
 >
 > The first question is "What is the current transaction?"  This
 > question is decided by the transaction manager.  An application could
 > chose an application manager that suites its need best.

application manager? Did you mean "transaction manager"?


 > Basic transaction API
 > ---------------------
 >
 > A transaction module or package can export a very simple API for
 > interacting with transactions.  It hides most of the complexity from
 > applications that want to use the standard Zope policies.  Here's a
 > sketch of an implementation:
 >
 > _mgr = TransactionManager()
 >
 > def get():
 >     """Return the current transaction."""
 >     return _mgr.get()
 >
 > def new():
 >     """Return a new transaction."""
 >     return _mgr.new()
 >
 > def commit():
 >     """Commit the current transaction."""
 >     _mgr.get().commit()
 >
 > def abort():
 >     """Abort the current transaction."""
 >     _mgr.get().abort()
 >
 > Application code can just import the transaction module to use the
 > get(), new(), abort(), and commit() methods.

Hm.  Does this mean that the transaction manager manages individual
transactions by thread?  This means that the definition of "current"
transaction becomes more squishy.

What about a model where there was a TM per thread.  Then, the methods
above would get the calling thread's TM and delegaet to it.
Similarly, one could create a new TM and use it to manage changes
independent of thread perhaps.

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

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

...

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

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




More information about the ZODB-Dev mailing list