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

[Christian Reis]

On Mon, Nov 04, 2002 at 02:45:27PM +0000, Toby Dickenson wrote:
> > 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.
> 
> Think about how this application would implement a correct Undo feature if it 
> was not using ZODB.... Probably with an architecture that involves 
> application-level transaction awareness.
> 
> IMO the application architecture is broken if it doesnt include this, with or 
> without ZODB.

Hmmm. I'm not sure I understand why using ZODB transactions for our
application would be "bad". If ZODB provides the machinery, and some
basic grouping/identifying of transactions could be done, then I think
we might be able to find a good solution. Yes, we'd have to handle
conflict errors and gb-uncreation problems in the app, but you'd end up
with those problems in your home-brew transaction system anyway.

Giving a bit more thought (but not an ounce of code ;) to it, I think
that I want can be done today; I just have a be a bit more careful about
controlling undo() - a wrapper for it might work, by using some bits in
the transaction (I know we have messages, and other nice trinkets) to
indicate to the application what "domain" it occured in; "not undoable"
could result if the order of the transactions made a clean undo
impossible.

To handle object unrefs, I'd probably go towards something you suggest,
but implement it by keeping a ghost copy of the instance attached to a
change interface, and syncronizing state to and from it when I wanted to
actually commit the changes (since I don't want other windows to see the
changes until somebody clicks on OK, for instance). This would probably
coincide with the ZODB commit().

I think the point in that last paragraph is that I will end up with 3
copies of the data: one in the ZODB, one in the instance, one in the
"ghost copy" of the instance. And I have the copies of the individual
attributes which are held in the UI widgets. 

Hmmm. Is your point that I am sketching out another layer of
transaction-awareness in my app? :-]

> > And, more importantly, how can this be solved? 
> 
> Keep the transactions out of your View, and avoid long-running transactions 
> altogether. I sketched out an architecture in M/V/C terms in this thread 
> yesterday.....

I saw that, but I still couldn't see why we couldn't use ZODB transactions
for precisely this purpose. Then again, I don't have as clear a view of
the issue as the ZODB wizards :-) 

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