[ZODB-Dev] Re: problem with aborting read-committed transaction

[Dieter Maurer]

Hi Adam,

Adam Groszer wrote at 2003-4-28 11:47 +0200:
 > _start is working fine now.
 > 
 > But I have again a small problem:
 > I have a hook (in a subclassed connection) in all transaction messages,
 > which in turn forward the messages to my persistent objects. I'm doing this
 > because I have to do some checking and registering with the objects.
 > 
 > I 'start' the transaction, 'do something'.
 > If everything goes well the transaction commits, my objects get the
 > following messages:
 > 	tpc_begin
 > 	commit
 > 	tpc_vote
 > 	tpc_finish
 > fine. If something goes wrong in the checking (done in tpc_begin) the
 > following:
 > 	tpc_begin (exception raised)
 > 	abort
 > 	tpc_abort
 > fine. If I want to abort, not commit the modifications the following:
 > 	abort
 > 	tpc_begin

You should also see a "tpc_abort".

 > now my code is wondering what's happening...
 > 
 > I found that the message order is the above because:
 >                 # DM: inform the jars that the transaction was aborted
 >                 #     such that they can refresh their state
 >                 #     ATT: this may require a new method as
 >                 #       "tpc_abort" may not be allowed
 > 
 >                 # do we need to merge in "subjars"?
 >                 for jar in jars:
 >                     jar.tpc_begin(self)
 >                     jar.tpc_abort(self)
 > the un-patched ZODB would send the following messages (I think):
 > 	abort
 > 	and nothing else?
 > 
 > What do you mean,
 > 	- is it OK to manipulate some objects in tpc_begin?
 > 	- should I write some work-around for the above?
 > When does ZODB 'restore' the previous state of the modified object, on which
 > message?

I need to clean up connection state after a transaction, whether committed or
aborted.
The unpatched ZODB allows this only for a committed transaction
(by modification of "tpc_finish" and "tpc_abort").

I abused "tpc_abort" for this cleanup.
Because "tpc_abort" can only be
called after a "tpc_commit", I added a "tpc_begin", too.

A the quoted comment above shows, I have been aware that this may
cause problems. If it does indeed, the correct way it to add
an explicit "tpc_cleanup" (or something similarly named) and call it
instead of the above "tpc_begin" and "tpc_end" additionally to
calling in in "tpc_finish" and "tpc_abort".


Dieter