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.