See
http://forums.activiti.org/en/viewtopic.php?f=6&t=2635&start=0
The underlying problem is that in the case of the process shown in the linked forum post, we have one root execution and 3 concurrent child executions. The child executions are continued asynchronously in three different transactions. When reaching the joining gateway, each transaction sets the property ExecutionEntity.forceUpdate=true on the parent execution. While this is not a persistent property, it nevertheless forces a new version of the parent execution to be committed hence the OptimisticLockingException.
This is totally fine from an engine/persistence point of view but maybe not what the user expects.
We can think about how to deal with this:
- simply accept it
or
- implement exclusive jobs (some hooks in the code and database schema already there)
I noticed that optimistic concurrency control is not something people seem to "get". We currently have a lot of forum threads/jiras concerning some instance of this. Maybe the job executor should do things "pessimistically" by default (exclusive jobs would be the default behavior and if you know what you are doing you can use sth. like activiti:exclusive="false" in order to enhance performance) ?
http://forums.activiti.org/en/viewtopic.php?f=6&t=2635&start=0
The underlying problem is that in the case of the process shown in the linked forum post, we have one root execution and 3 concurrent child executions. The child executions are continued asynchronously in three different transactions. When reaching the joining gateway, each transaction sets the property ExecutionEntity.forceUpdate=true on the parent execution. While this is not a persistent property, it nevertheless forces a new version of the parent execution to be committed hence the OptimisticLockingException.
This is totally fine from an engine/persistence point of view but maybe not what the user expects.
We can think about how to deal with this:
- simply accept it
or- implement exclusive jobs (some hooks in the code and database schema already there)
I noticed that optimistic concurrency control is not something people seem to "get". We currently have a lot of forum threads/jiras concerning some instance of this. Maybe the job executor should do things "pessimistically" by default (exclusive jobs would be the default behavior and if you know what you are doing you can use sth. like activiti:exclusive="false" in order to enhance performance) ?
I totally agree with you and I think that the second choice is by far the right one, it will add a great value to the engine. 
We can think about how to deal with this:
- simply accept it
- implement exclusive jobs (some hooks in the code and database schema already there)
Is there another solution?
None of the solutions above will work for me.
The requirements I have are as follows: given this process (same as the original post):
[img]http://dl.dropbox.com/u/175705/Screen%20shot%202011-10-30%20at%206.03.10%20PM.png[/img]
1. Tasks A, B and C have to be parallel (the time it takes between the parallel gateways can't be time(A) + time(B) + time(C)).
2. Task A, B, and C can be called only once (can't be rolled back)
So the A, B and C tasks need to be parallel (activiti:async="true" activiti:exclusive="false").
The solution is very well explained in the activity 5.9 user guide http://www.activiti.org/userguide/index.html#exclusiveJobs and this is exactly was I was looking for except for the issues mentioned when joining the tasks.
I understand the need for the optimistic locking and it will work for me if the retry will only retry the join transition and not call the execute on the service task again. Otherwise the task would book the flight again and again for every retry.
I guess that means the task transaction is separate from the activiti engine transition transaction.
Is there a difference if A, B and C are user tasks instead of service tasks and they're completed concurrently in different threads?
Would this solve the problem?
Looking forward for your input.
TIA.
Ion
