Transaction boundaries on errors.

[bwd]

Hi,

I have a workflow that has a user task followed by a java service task.  I ran a test where the task was completed, after which the java service task ran, which threw an exception (due to a data error on my part).  My expectation was that the task itself would be complete (because it had to be completed for the subsequent service task to execute).  However, I find that when I query for active tasks, this task is showing up again.  This leads me to believe that the transaction scope is from the task completion action to the next halting point (another user task, end of process, …, etc) instead of having individual transactions per construct in the BPMN description, and that the error is causing a rollback to the point immediately prior to the task completion point. 

Is my understanding of the transaction boundaries correct?  Is there any way to adjust it through configuration?  (I don't see support for the BPMN 'Transaction Sub-process'.)  What if there was some non-transactional construct between the user task and the java service task that doesn't support transactional semantics (ex: sending an email notification).

Thanks,

BD

[bwd]

I do see this in the FAQ: http://www.activiti.org/faq.html#WhatIsTheDifferenceBetweenProcessConcurrencyAndJavaConcurrency

"The behavior of Activiti Engine to calculate possibly multiple steps in a process until a wait state is reached is the default behavior. Asynchronous continuations will be introduced to allow for a more fine grained demarcation of transactions for those situations where it is needed."

Does this mean that we can rely on having a single transaction for a sequence of constructs that don't contain a wait construct?  If so, is this the long-term behavior, or is it subject to change as the engine evolves?

Thanks,

BD

[ronald_van_kuij]

Does this mean that we can rely on having a single transaction for a sequence of constructs that don't contain a wait construct?

Yes

If so, is this the long-term behavior, or is it subject to change as the engine evolves?

Both, since it is a non-bpmn construct, it might be subject to (small) changes/improvements I think, but stable enough to rely on it for llong term