[Zope-dev] ZPatterns (sub-)transaction problems

Phillip J. Eby pje@telecommunity.com
Thu, 14 Sep 2000 09:37:18 -0500


At 01:41 PM 9/14/00 +0100, Steve Alexander wrote:
>
>I think there's something not quite right about the way ZPatterns is
>handling subtransactions, even with this patch, and the other one
>related to Transactions.py that I posted a while back.
>
>Is there any detailed documentation about how Zope transactions and
>subtransactions are supposed to work?
>

Unfortunately, the problem is not with Zope but with ZPatterns.  I was
about to announce this today anyway, but I figured I might as well do it by
replying to your post.

The ZPatterns transaction machinery is seriously broken with respect to
subtransactions.  It is mostly functional with respect to "plain"
transactions.  It has been broken since its inception due to a design
stupidity on my part.  Under pressure to get a working 0.4.0 system, I
started coding without a fully thought-out design for the transaction
handling system, and changed it midway two or three times before I got
something that (basically) works.

I did not discover the flaws until yesterday, when Ty tried to use
subtransactions in a to-be-production application.  An hour or so of
debugger-stepping and Zope-source-reading later, we were able to fix the
code to allow a single subtransaction commit to succeed, but *only* if no
work were done following the subtransaction commit.  <sigh>

I will try to have a ZPatterns snapshot release made this week that will
include those fixes (plus the fix for a problem with DynPersist that we
also discovered yesterday).

It should be noted, however, that the resulting release will still not be
good for much with respect to subtransactions.  I am in the process now of
redesigning the entire transaction machinery to correct the problems.  On
the bright side, I have already seen how the redesign will simplify the
code of several classes, while possibly improving both performance and
memory usage.