Both parallel tasks are async. I have done some tests and I got stuck with race condition. Two threads want to change the state of the same process at the same time. I get Optimistic lock exception. I know that in a production environment, such situation will be rare, but I want to be prepared for that kind of situation. So I’m wondering if there is a solution in jbpm which can be applied out of the box? I have done some research and unfortunately I didn’t find any.

Also I tried to rewrite query which gets RequestInfo records to be more aware of currently executing processes but without success.

that is sort of expected if you attempt to change same data base entry - process instance. Even though process instance should be completed properly because there is by default optimistic lock exception interceptor that will retry failed command which in case of async tasks is completeWorkItem so it should be safe from execution point of view - meaning the async job itself should not be retried (reexecuted) because of that exception.

I am working with Adrian on solution of parallel tasks problem. After OptimisticLockException jbpm executor is updating RequestInfo with status RETRYING so it is retrying one of async tasks.

We have workaround: in AsyncWorkItemHandlerCmdCallback before calling completeWorkItem we have added em.find(ProcessInstanceInfo.class, processInstanceId, LockModeType.PESSIMISTIC_WRITE); to lock row in ProcessInstanceInfo. It works now without any exception but is it a valid soltion? If it is can it be part of next jbpm release?

in general if yo need to you can enable pessimistic lock for the project via deployment descriptor - environment entry.

The optimistic lock exception should be on process instance level so it should not reattempt to run the job but it should be handled by ksession to retry the given command. Could you please provide complete stack trace for this issue? And what version are you running on?

I have already tried to enable pessimistic locking and it changed the query to SELECT ... FOR UPDATE NOWAIT so there was an exception (different than OptimisticLockException) - it works more or less the same.

so the problem seems to be due to both bitronix and spring do not provide real cause of the exceptions and return only that transaction was rolled back. This is why optimistic lock retry interceptor was not properly invoked. Though as a workaround you could set it to another class that in this case is shown. Simply add system property argument to the application and it should handle the retry properly: