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

[Jeremy Hylton]

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

  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?

Jeremy