interrupting boundary event on subprocess

[peter.hac...@googlemail.com]

Hi,
we'd like to model a subprocess that can be interrupted by a message. A boundary message event seems to be the perfect fit, but we are unsure about the consequences.
- Is the subprocess interrupted immediately? Or are the transactions opened in the subprocess finished, first?
- Are currently running transactions of the subprocess rolled back?
- Does the boundary event wait until the subprocess is terminated completely before it continues with the execution of edges going out from the boundary event?

Thanks, Peter

[Daniel Meyer]

Hi Peter,

(sorry for the late answer, seems like this one fell through the cracks of the general "we need to release 7.0.0-Final agitation"):

Concurrency is solved using optimistic locking: 

If one thread is currently doing execution in a process instance and a second thread tries to cancel that execution, one of these threads will fail with an optimistic locking exception.

The mechanism is the same as when you use JPA or Hibernate and update the same entity object concurrently. 

- Is the subprocess interrupted immediately? Or are the transactions opened in the subprocess finished, first?

There is no "waiting": there will be one thread execution the subprocess and one thread executing the boundary event. If the transactions overlap, one of the theads will "loose", commit second and fail with an optimistic locking exception. It can be either the thread active in the subprocess or the thread executing the boundary event. The corresponding transaction will roll back and has to be retried. This is a schematic illustration:

- Are currently running transactions of the subprocess rolled back?

=> It depends on wether the execution of the subprocess or the execution of the boudary event commits first. the second one is rolled back.

- Does the boundary event wait until the subprocess is terminated completely before it continues with the execution of edges going out from the boundary event?

=> No: both the execution of the subprocess and the execution of the boundary event are prone to optimistic locking.

Cheers,

Daniel Meyer

[peter.hac...@googlemail.com]

Hi Daniel,

thanks for the reply. I'm not sure whether I got it 100%. So, is it the transaction of the boundary event that does the interrupt of the subprocess? If that is so, I could start the first task after the boundary event with a new transaction. That would guarantee that the subprocess is dead and cleaned up before I perform any business logic in the main process. Is this correct?

Greetings, Peter

[Daniel Meyer]

Hi Peter,

 

So, is it the transaction of the boundary event that does the interrupt of the subprocess?

Yes, indeed. The process engine is a simple state machine: when the boundary event is triggered, a new transaction will be started. This transaction checks out the state of the process instance from the database, deletes the execution for the subprocess and tries to commit. If in the meantime (after the state was loaded from the database and before the delete was committed) another transaction changed the state in the database, an optimistic locking exception will occur and the transaction will roll back.

 

I could start the first task after the boundary event with a new transaction. That would guarantee that the subprocess is dead and cleaned up before I perform any business logic in the main process. Is this correct?

Yes.

 

Cheers,

Daniel Meyer