(woops, forgot to cc the list when answering) Le Vendredi 8 Février 2008 22:41, vous avez écrit : > Where does this "cleanup" code comes from -- from your application?
Yes (explanation folows). > "try: ... except: ..." are extremely dangerous -- never use them. > > If you think you need something like this, always use > > try: ... > except ConflictError: raise > except: .... What it does with more details is: - fetch a task from a task list and put it in "being processed" state - execute the task - update the task list: delete task if successfull, otherwise put it back to a "pending" state Task execution request is generated by timerserver. Tasks are executed in a loop (no need to wait for next timerserver poll if application knows it still have tasks to process), and to make a task's result independant from other tasks' success, I must commit/abort during the transaction depending on task success. So I need to intercept conflict error from the "execute the task" phase, otherwise I will get tasks in a "being processed" state, causing them to stall untill state gets fixed by hand. As task list is shared among multiple Zope instances (to paralelize task execution) I need to make modifications to this list visible to other nodes as soon as possible, to prevent multiple nodes from processing the same task. All suggestions improving those design choices are welcome. > In my Zope 2.8.1, this does not happen -- probably a bug that > has been introduced later. Mmh, the code was here from revision 3436, which is an initial import: http://svn.zope.org/ZODB/trunk/src/transaction/_transaction.py?rev=3436&view=markup (see below "def register") Note that the problem was triggered by a bug in my application: I was trying to use a connection not yet registered with transaction manager after the transaction failed to commit and before aborting it... Transaction class does detect this as a problem, but only after modifying its data (the "append" I mentioned). And it is worsened by TM hiding the exception raised in Transaction. > I would check whether the problematic code is still in the > current Zope version. If so, I would file a bug report. Code I think should be canged is still in Zope 2 trunk (TM.py), and still in transaction trunk (_transaction.py), so I'll bugreport. -- Vincent Pelletier _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )