topic Re: How to handle or avoid an optimistic locking exception in Alfresco Forum

How to handle or avoid an optimistic locking exception

schmke — Fri, 17 Mar 2017 18:21:19 GMT

I have an interesting scenario using 5.21 (moving to 5.22 and perhaps 6 soon) where I'm getting an ActivitiOptimisticLockingException. I'd like to figure out the best way to handle it or avoid it entirely.I have a process that has a user task that on completion has Java service task that calls an AP

Re: How to handle or avoid an optimistic locking exception

jearles — Fri, 17 Mar 2017 20:47:48 GMT

Schmke,

You've been heard, and actually there's another post about something similar that we're looking into. I need to look into this a bit further; if you have a minimalistic reproduction, that would help a lot.

In 2013, one of the Activiti gurus commented on this same issue saying that: "This exception will only happen if you have multiple Activiti Engines with the job executor activated." Can you verify that this isn't the case?

Thanks,
-JEarles
bp3

Re: How to handle or avoid an optimistic locking exception

gdharley — Fri, 17 Mar 2017 21:28:09 GMT

As far as I know Version 6 will not resolve this issue as it really isnt a defect.

The current instance IS a related instance and therefore is being returned correctly.

You can either exclude it from the set of instances being deleted, perhaps by including the current instance ID in the message and excluding it on your message handler, or you could change the order of processing, perhaps by delaying the firing of the message until after the current instance gets to a wait state.

Hope this gives you some ideas,

Greg

Re: How to handle or avoid an optimistic locking exception

schmke — Tue, 21 Mar 2017 18:38:38 GMT

Correct, there is just one Activiti engine running.

I don't think the other scenario is related, mine is just one where a Java service task triggers something external to delete a process instance that happens to be the process instance the Java service task ran as, and it all happens quickly enough that the engine isn't done finishing up the process instance completion when the delete happens. I sometimes get the exception in the delete and sometimes back to the client that completed the task.

Is there any way for the asynchronous delete to check/know that the process instance is "in process" other than getting the exception? If the exception only occurred in the client doing the delete, that would be fine, but it potentially happening on the process engine where the task is being completed and that seems like it would cause problems.

Re: How to handle or avoid an optimistic locking exception

schmke — Tue, 21 Mar 2017 18:43:28 GMT

Thanks for the reply.

The delete is presently asynchronous and doesn't know anything about the current instance ID unfortunately. Ideally the engine would provide a way for the client doing the delete to know the instance is "in process" but I haven't determined a way to do that yet. I considered doing a query to see if the instance has tasks (there should be none after the task is completed) but it appears that hasn't been persisted yet when the delete happens.

I could add a delay before trying the delete, but that feels like a hack and how long a delay is long enough? I'm sure it would depend on the steps in the process after the Java service task that triggers the message causing the external delete.

I could set a variable right after task completion to allow the delete to filter this specific one out, but if the instance is still being processed, will that variable be persisted yet and seen to be filtered on?

Re: How to handle or avoid an optimistic locking exception

haridaniel — Wed, 29 Nov 2017 18:02:44 GMT

How you can verify "have multiple Activiti Engines with the job executor activated" ? Thanks!