[ZODB-Dev] ZODB4 project plan

Shane Hathaway shane@zope.com
Tue, 03 Dec 2002 11:07:32 -0500


Christian Reis wrote:
> On Tue, Dec 03, 2002 at 10:36:43AM -0500, Jeremy Hylton wrote:
> 
>>  GW> OK, not *every* application.  I over-stated the case.  But the
>>  GW> one-thread-one-transaction policy is arbitrary and it's just
>>  GW> that -- a *policy*.  As a general purpose-library, ZODB should
>>  GW> provide mechanism, not policy, whenever possible.
>>
>>I don't know why I'm beating you up on this, but you started it
>><wink>.  It's not even an arbitrary policy.  It's a really good policy
>>for a lot of simple applications.  We're in violent agreement that it
>>should be possible to choose other policies, but I think the current
>>one is a fine default.
> 
> 
> (since we're being violent ;) Why is the policy of
> one-connection-one-transaction-scope a bad default? Or why is it worse
> than the current one? I find having multiple connections but a single
> transaction "scope" confusing, at least.
> 
> You can read that as a +1 for changing the policy to a transaction per
> connection. :-)

I just checked in code to ZODB (on a branch) that enables you to change 
the policy.  Check out shane-local-transactions-branch.  From the 
checkin message:

The Connection class now has a method setLocalTransaction().
(Suggestions for a better method name accepted.)  Once your app calls
this, your app is expected to use connection.getTransaction() or
ob._p_jar.getTransaction() instead of the get_transaction() function
to commit or abort the transaction.  Doing this enables your
application to have multiple writable connections open in a single
thread, which is especially usefully in GUI applications.

If you don't call setLocalTransaction(), ZODB behaves as it always
has, with transactions bound to threads.

Shane