topic Re: ActivitiOptimisticLockingException Retry in Alfresco Archive

ActivitiOptimisticLockingException Retry

thane — Wed, 27 Aug 2014 00:42:25 GMT

Hi,sometimes ActivitiOptimisticLockingException's like VariableInstanceEntity[id=99, name=nrOfCompletedInstances, type=integer, longValue=1, textValue=1] was updated by another transaction concurrently‍‍‍occur and the hole process is stalled until the job ist executed again. Reducing lockTimeInMilli

Re: ActivitiOptimisticLockingException Retry

jbarrez — Sat, 30 Aug 2014 17:56:46 GMT

Are you running multiple nodes? Or are different threads/users are accessing the same process?

If so - the exception is expected when the same variable is updated by two threads - one shall be rollbacked, the other wins. So it is safe to retry the failing one (but it will now change the variable value to that particular value)

Re: ActivitiOptimisticLockingException Retry

thane — Sat, 30 Aug 2014 23:47:12 GMT

Hi,

indeed the exception is not suprising. I'm just wondering about the behaviour after the exception occured.
[img]http://s7.directupload.net/images/140831/2tfu36ha.png[/img]

Two users A,B complete their User Task concurrently. One transaction looses and we get something like:
org.activiti.engine.ActivitiOptimisticLockingException: VariableInstanceEntity[id=12513, name=nrOfCompletedInstances,…

Let's say user A won, the job (execute the Service Task and end instance), triggered by user B, remains in the database until LOCK_EXP_TIME_ is reached and is executed again afterwards. So the hole process could be stalled for lockTimeInMillis (^= 5 minutes), which is not necessary in this context. (single node, multiple users)

ciao,

kai

Re: ActivitiOptimisticLockingException Retry

jbarrez — Mon, 15 Sep 2014 09:39:31 GMT

Indeed - in such a setup it is indeed not helpful. However, this case is different because it's a user task, there is no job involved.

In this case, you could catch the exception and retry yourself, without delay.