[ZODB-Dev] Re: [Zope-Checkins] CVS: ZODB/src/ZODB - ZApplication.py:1.14

[Shane Hathaway]

On Fri, 16 Apr 2004, Jeremy Hylton wrote:

> On Fri, 2004-04-16 at 11:07, Shane Hathaway wrote:
> > I'm quite surprised by this change.  Since the name "transaction" refers 
> > to a module, something is required to guess that transaction.commit() 
> > should commit "conn".  One way to make that guess is to bind 
> > transactions to threads, but why guess?  With 
> > conn.getTransaction().commit(), at least there was no need to guess.
> 
> The use of getTransaction() only makes a difference if
> setLocalTransaction() was called first.  Since it wasn't called in this
> code, then conn.getTransaction() would in turn call transaction.get().
> In theory, the connection could be bound to a different transaction --
> but only if you ignore the call to db.open() just two lines above.
> 
> We've started revising the transaction API as described in the Wiki page
> I posted several weeks ago.

Yes, I read it, though I didn't study it.  I didn't think you were going
to act on it yet, because I thought there were open objections.

I just took a deeper look at the latest changes to Connection.py, and it's
looking great.  A connection holds a reference to its transaction manager.  
That will work fine.  Calls to transaction.get/begin/commit/abort within
ZODB code worry me, though, because they assume thread-bound transactions.  
Perhaps Connection should have an API for getting its transaction 
manager, and we should use that instead of transaction.get().

For most ZODB users, the distinction between transactions, connections,
and threads is very blurry, making ZODB harder to learn than it could be.  
To make it clearer, how would you feel about moving
transaction.get/begin/commit/abort to a module within the transaction
package, telling ZODB users that by using those functions, they are
choosing the transaction-per-thread policy?  People would type something
like "transaction.thread.get()" instead of "transaction.get()".

Shane