[ZCM] [ZC] 915/ 6 Reject "exception in one of many dtml-try rolls back entire Zope transaction including those outside of the failed dtml-try"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #915 Update (Reject) "exception in one of many dtml-try rolls back entire Zope transaction including those outside of the failed dtml-try"
 Status Rejected, Database/bug critical
To followup, visit:
  http://collector.zope.org/Zope/915

==============================================================
= Reject - Entry #6 by ajung on May 29, 2004 3:13 am

 Status: Pending => Rejected

I am rejecting this issue since I see no indication
for a bad behaviour of Zope. Having had some smiliar
problems with the transaction handling using PsycopgDA
I am going to blame the DA (which in fact is more stable
and robuste in the latest releases).
________________________________________
= Comment - Entry #5 by aho on Jun 27, 2003 5:58 pm

Issue partly resolved through change in Psycopg database adaptor (http://www.initd.org) as of version 1.1.5.1. 	

entry in Change Log for Psycopg 1.1.5.1:
* ZPsycopgDA/db.py (DB.query): if a query raise an exception,
  first self._abort() is called to rollback current
  "sub-transaction".  this is a backward-compatible change for
  people that think continuing to work in the same zope transaction
  after an exception is a Good Thing (TM).

I think it would still be nicer if Zope can isolate each sub-transaction in dtml-try block so that code within the block cannot not abort code outside the dtml-try block.
________________________________________
= Comment - Entry #4 by aho on May 17, 2003 12:40 pm

This issue may be limited to the Psycopg adaptor. However, if that is the case, then Zope may still need to be fixed. The reason is that the transaction control mechanism, as provide by try-except, is handled by Zope. Zope needs to enforce a consistent behavior for try-except no matter what kind of code is enclosed within any try-except block.

I think it is reasonable for Zope to identify and manage each block of try-except code as a single, atomic sub-transaction. Failure of any sub-transaction ought not lead to the rollback of the container transaction. On the other hand, failure of the container transaction should rollback all sub-transactions.

Therefore, I don't think the fix should be in the Psycopg code. I think Zope should be able to overrule whatever Psycopg thinks should take place - if Psycopg is being called from within Zope.

As is, either 1) Zope ceded control of transaction management wrongly to the database adaptor, or 2) is signalling psycopgDA wrongly regarding the status of the parent transaction.

I sent a message to Federico Di Gregorio who works on the Psycopg project regarding this bug. Let's see whether he agrees.

________________________________________
= Comment - Entry #3 by ajung on May 17, 2003 12:19 pm

Could you please outline if this is a Zope problem or a PsycopgDA
problem? 
________________________________________
= Comment - Entry #2 by aho on May 17, 2003 12:07 pm

I just found this :
  http://lists.initd.org/pipermail/psycopg/2003-March/001934.html
Maybe this is not a bug - it is a new feature? :-)

I still think this is a bug.
________________________________________
= Request - Entry #1 by aho on May 17, 2003 11:00 am


Uploaded:  "test.zexp"
 - http://collector.zope.org/Zope/915/test.zexp/view
Limitations:

I have only tested this with the PsycopgDA adaptor (several versions - upto 1.1.4). I don't know if the problem is with the adaptor - but my guess is not. Since the same adaptor works fine in Zope 2.5. I am also notifying the Psycopg team - maybe they can help.

Bug:

This bug causes the entire Zope
transaction to rollback (= not committed) even though an error is caught
by the dtml-try / except tag. Thus, this bug is meaningful when we don't
want the entire transaction to rollback. In fact, that's why the dtml-try
command is used to "try" a specific block of code - allowing the rest of
the code to be executed even if that one block of code causes an error.

I am uploading a zexp file containing 2 sets of test code. The first one tests the dtml-try without ZSQL (which works fine), the second (test2_for_dtml_try_bug) shows the error. Running the second test requires that you have a database connection. I cannot replicate the error using Gadfly.





==============================================================