[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