Transaction Isolation, was Re: SystemSpecifyer, was Re: [ZODB-Dev] How to predict George Bailey?

Christian Reis kiko@async.com.br
Mon, 4 Nov 2002 12:24:05 -0200


On Sun, Nov 03, 2002 at 07:36:33PM +0100, Magnus Lycka wrote:
> Let's pretend this is a word processor. Should I drop and
> reload my document every time I press Ctrl-S or Ctrl-Z?

No, and this brings up a question for the ZODB wizards.

With this discussion, I became aware of the issues that are related to
having unrelated (in the domain sense) objects changing during a single
transaction - meaning you have a transaction that changes an object here
but also there just because you happened to commit() on the second
change. 

It also shows that there is an issue with Undo, because if you just
blindly Undo you can't be sure you are undoing changes that were done to
that specific *part* of the application or to something completely
different.

Am I wrong?

And, more importantly, how can this be solved? I have some questions
about how ZODB works exactly:

- A transaction is a "global" concept, tied to the thread, right? This
  is why it can be in builtins (if multiple transactions could happen
  in the same thread simultaneously, get_transaction() would be
  ambiguous).

- I can do multiple DB.open()s, IIRC. How do transactions map to
  connections? I.E. if I have, in the same thread, multiple connections
  open, and I alter objects in both, what does get_transaction() give
  me? 

- If the application were susceptible to it, would it make sense to
  split Magnus' application into separate threads, so that changes could
  be isolated in some way? We could run a separate thread when we open
  an edit dialog, for instance, and make sure that that transaction was
  independent, so abort() and commit() would be safe. (Magnus' app
  probably can't be separated into threads, I know. But he could use the
  next option: )

- And finally, would it make sense to have "transaction groups" or
  "transaction domains" in which you could tie changes to related
  objects (again, in the domain sense) together, and later specify the
  group ID to Undo, commit and abort? I have a hard time thinking how we
  could bind changes to a certain group because of the transparent
  nature of ZODB, but maybe somebody has an idea.

  (To a certain measure, the thread acts as this "transaction grouper",
  but without the group ID)

We're doing a lot of work to push ZODB in our region, and lots of people
are interested, and I guess these questions are going to show up.
Comments from those "in the know" would be appreciated! 

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