(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
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:
(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.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -