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