[ZODB-Dev] Re: [Zodb-checkins] CVS: Zope/lib/python/ZODB/tests - testZODB.py:1.6.6.1

[Shane Hathaway]

Jeremy Hylton wrote:
>>>>>>"SH" == Shane Hathaway <shane@zope.com> writes:
>>>>>
> 
>   SH> Update of /cvs-repository/Zope/lib/python/ZODB/tests In
>   SH> directory cvs.zope.org:/tmp/cvs-serv13538/tests
> 
>   SH> Modified Files:
>   SH>       Tag: shane-local-transactions-branch
>   SH> 	testZODB.py
>   SH> Log Message: Enabled decoupling of ZODB connections and
>   SH> transactions, a feature requested often on the zodb-dev list.
> 
>   SH> The Connection class now has a method setLocalTransaction().
>   SH> (Suggestions for a better method name accepted.)  Once your app
>   SH> calls this, your app is expected to use
>   SH> connection.getTransaction() or ob._p_jar.getTransaction()
>   SH> instead of the get_transaction() function to commit or abort the
>   SH> transaction.  Doing this enables your application to have
>   SH> multiple writable connections open in a single thread, which is
>   SH> especially usefully in GUI applications.
> 
> How do we deal with transactions involving multiple connections?
> Perhaps I misunderstand mounted storages, but don't they involve
> several independent jars that are coordinated by registering with the
> same transaction.  Don't we see the same problem if a transaction
> involves, for example, a ZODB connection and a database adapter?

Mounting is Zope-specific.  Zope does not use the new policy, so 
mounting doesn't interact with this.

Someday we'll enable inter-database references, at which time we may 
have to figure out how to ensure the transactions span all involved 
connections.

>   SH> This feature is experimental, but the implementation seems about
>   SH> right.  Unfortunately I had to change the CommitVersion,
>   SH> AbortVersion, and TransactionalUndo classes so that instances
>   SH> don't automatically register themselves with the transaction,
>   SH> but they should not have been doing that in the first place, and
>   SH> hopefully these classes aren't being used directly by
>   SH> applications.  Most apps will see no change.
> 
> Why shouldn't CommitVersion &c. register with the current transaction?

Because they don't necessarily have any way to find out what the current 
transaction is.  get_transaction() assumes thread-bound transactions.

Besides that, it is generally bad form for a constructor to 
automatically put the constructed object somewhere, when it is just as 
easy and safe to do the same thing outside the constructor.

Shane