topic org.activiti.engine.ActivitiOptimisticLockingException in Alfresco Archive

org.activiti.engine.ActivitiOptimisticLockingException

mlisiewicz — Fri, 25 Mar 2011 14:00:45 GMT

Given exception is thrown when two executions try to update their state at the same time. Please download attached activiti file and run simple test on it.Engine revision 5.3, databases checked: mysql, h22011-03-25 14:51:20 org.activiti.engine.impl.interceptor.CommandContext closeSEVERE: Error while

Re: org.activiti.engine.ActivitiOptimisticLockingException

jbarrez — Mon, 28 Mar 2011 09:07:44 GMT

That is the expected behavior: in you case, the two tasks are trying to do something at the same time with the same process instance.
The engine can't possibly know how those must be merged in the generic case (in this case, you can just see it), so one transaction 'wins', and the other is rolled back.

So if you want to deal with this, you will need to catch this exception and implement a reload or retry (depending on your use case)

Re: org.activiti.engine.ActivitiOptimisticLockingException

lichtin — Fri, 09 Sep 2011 11:49:25 GMT

I'm trying to understand this situation and am at a loss.
Why and how does the code identify above scenario as an 'optimistic lock exception'?

There are 2 receive tasks and each task has a boundary timer (3 secs) attached.
Both timers fire and then the process ends. There's no variables to merge.

Re: org.activiti.engine.ActivitiOptimisticLockingException

ronald_van_kuij — Fri, 09 Sep 2011 13:23:45 GMT

but there is a proccess to end

Re: org.activiti.engine.ActivitiOptimisticLockingException

franz1 — Thu, 06 Oct 2011 06:52:35 GMT

That is the expected behavior: …
The engine can't possibly know how those must be merged in the generic case (in this case, you can just see it), so one transaction 'wins', and the other is rolled back.

So if you want to deal with this, you will need to catch this exception and implement a reload or retry (depending on your use case)

How "big" are those transactions (i.e what is covered by one transaction? Execution of a single task, entire execution till it reaches a receive-task/end?) And is there a way to influence the size of such a transaction (even if you are using Spring in an EJB (with user-managed transactions))?

"OptimisticLocking" sounds like first Activiti tries to do something and only then to check if it was allowed to do it. If that's correct and if I have a service-task starting an asynchronous external process followed by a receive-task waiting for the asynch process to continue - this should mean that the external process is already started when Activiti realizes that it would have been better not to do so and rolls back - which in consequence means that the process can't signal that it has terminated.

This behaviour would be a "no-go" and should be corrected ASAP - Ideally there would be a configuration-option that Activiti checks before each step if it is allowed to perform it - even if it comes at the cost of performance-loss.

Best regards

Franz