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

[Christian Reis]

On Mon, Nov 04, 2002 at 04:10:50PM +0100, Magnus Lycka wrote:
> Conceptually, one might well imagine that I perform the steps
> A, B, C, D, and I realize that B was wrong, and should be
> undone. It would be difficult to know if C and D depend on
> B though, so I think it's reasonable that the user will have
> to undo C and D as well, or repair whatever was wrong with B.
> 
> It might be some work for me to define transaction boundries
> better than today, but I'm sure this can be done. Then it would
> be clearer in what steps I can undo things. Maybe I could use
> the message parameter to the commit to save some info that
> will help me with undo?

Yep, just thought of that option myself; store some metadata in the
transaction to help the application know what was going on at the time.

> Eventually I'll use ZEO and a multi user setup I guess. Then
> I'm sure there will be all sorts of concurrency issues to solve.
> Undo will certainly be more complicated then. It seems difficult
> to allow undo of something that has been made available to other
> users in the system. Might sub-transaction ne helpful here?

Have you thought about using threads internally? I have the impression
that the thread keeps its own connection, and will see its own copy of
the objects; an undo in that case would only operate locally. Of course,
you would still have to handle conflicterrors, but I most applications
can be structured to avoid this effectively.

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