[ZODB-Dev] transacting multiple databases

[Christian Reis]

On Tue, Dec 10, 2002 at 10:38:21AM -0500, Jeremy Hylton wrote:
> >>>>> "SH" == Shane Hathaway <shane@zope.com> writes:
> 
>   SH> I think the next step is to decide whether the
>   SH> setLocalTransaction() code ought to be merged into mainline
>   SH> ZODB.  I'd be happy to do it with Jeremy's approval.  (Jeremy,
>   SH> are you reading?)
> 
> I'm reading, but I haven't had time to follow setLocalTransaction().
> What is the rationale?  Maybe we could do a mini-PEP?

Shane's change has made it possible for us to work in a much cleaner
fashion in our GUI application. The problem of having transactions tied
to threads is that, for applications that use other `multitasking'
approaches (such as mainloops that most UI toolkits offer) there is no
way to isolate changes committed.

This means that if I have two windows open that are modifying instances,
the get_transaction().commit() call is global, no matter in which
context it is issued (quite obviously, since there is a single thread).
If I am editing a product in dialog A and a customer's data in dialog B,
and I tie commit() to the OK button on dialog A, I am committing changes
to both the product and the customer, even though I didn't touch the
customer's OK button. Oops. Ideally, I should be able to separate the
transactions per window.

Shane's change allows us to localize a transaction to a specific
connection. We use one connection per dialog, and in this way we can
call commit() safely on each OK click without fear of making changes
anywhere unrelated. 

To anybody who's used ZODB in a UI environment with more than a few
dialogs the value of this is quite clear, and I suspect it makes the
ZODB more flexible in the general non-Zope case too.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL