[Zope-dev] transaction support for ordering transactions.

[Anthony Baxter]

>>> "Phillip J. Eby" wrote
> There is an error in your patch, however. _prepend should use
> self._objects.insert(0,object), as the way you're doing it now will break
> the _append method.  (Because _append is a reference to _objects.append,
> and you're replacing the old _objects with a new list.  Subsequent calls to
> _append will append the object to the old _objects list, not the new one
> you've just added.)  

Darn. That'll teach me to make a quick patch like this. Still, getting the
feedback is the key thing - I wasn't sure if the approach I was taking was
the right one.

> There is also a *second* problem with your patch, which is more serious and
> less correctable.  If a _prepend takes place *during* a commit operation,
> the current implementation of the commit operation will be blown all to

Ugh. Ok, how about then just doing something like not allowing a prepend
once the committings already started?

> Anyway...  I'm very much in favor of solving the same problem that you
> are...  But it requires a rather more complex patch (so that
> transaction.commit() could deal with prepends during commit) and first we'd
> need to convince Jim that it's the right thing to do.  :)  (Not only that,
> but he might come up with a better way to do it than prepending...)

He does tend to do that. I'd very much like a way to fix this - at the
moment, the only workaround for me is for SQLSessions to have an entirely
different database connection to themselves.

> Ironically, I'm not sure your problem actually *needs* this fix to be
> solved.  You probably need to tie your session object's behavior to an
> earlier transaction event (the "_p_jar.commit()" operation rather than
> tpc_finish()), and you can then be guaranteed that the SQL connection has
> not yet seen a tpc_finish() either.

I'm not sure I understand this - are you suggesting hooking it to the 
database connector's commit?

> *My* problem, on the other hand, is that even if I do this, ZODB does not
> allow objects to be _p_jar.commit()ed twice; if you modify an object which
> has already been _p_jar.commit()ed in the same transaction, you will get an
> unresolvable ConflictError (because the ZODB thinks another transaction
> modified the object before you). 

Ugh. Nasty nasty. But hey, isn't the whole point of ZPatterns to expose 
all the nasty corners of the Zope innards to light?

> Thus, I need to ensure that DataManagers
> which are saving things up 'till a _p_jar.commit() operation, get
> registered ahead of any modification to an object that they might need to
> modify again later.  So a fully functional "prepend" capability would be of
> great benefit to ZPatterns, but I'm not sure that your problem actually
> needs it, and your patch, unfortunately, does not achieve it.

Thanks for the feedback - time for me to hit the source code again. :)

Anthony