[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