-
1. Re: Parallel async tasks
swiderski.maciej May 11, 2015 1:52 AM (in response to adrianch)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.
HTH
-
2. Re: Parallel async tasks
mraszplewicz May 11, 2015 9:50 AM (in response to swiderski.maciej)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?
-
3. Re: Parallel async tasks
swiderski.maciej May 11, 2015 9:55 AM (in response to mraszplewicz)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?
HTH
-
4. Re: Parallel async tasks
mraszplewicz May 11, 2015 7:25 PM (in response to swiderski.maciej)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.
You can find my sample project here: mraszplewicz/spring-boot-jbpm-parallel · GitHub it is based on your jbpm-examples/spring-boot-jbpm at master · mswiderski/jbpm-examples · GitHub. To start application simply run pl.mrasoft.jbpm.parallel.Application.main (or mvn spring-boot:run) and then go to http://localhost:8080/parallel/start in your browser.
Please find log file attached. There are two occurrences of "Executing AsyncCommand2", should be one.
-
5. Re: Parallel async tasks
swiderski.maciej May 12, 2015 12:42 PM (in response to mraszplewicz)Maciej,
thanks for reproducer, well done!
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:
-Dorg.kie.optlock.exclass=org.springframework.transaction.IllegalTransactionStateException
with that executor should not retry command itself but only reattempt to complete work item.
HTH
-
6. Re: Parallel async tasks
mraszplewicz May 13, 2015 2:46 AM (in response to swiderski.maciej)Thank you Maciej!
Now it works as expected.
Is it documented somewhere?
-
7. Re: Parallel async tasks
swiderski.maciej May 14, 2015 2:00 AM (in response to mraszplewicz)some details are mentioned in jira though not sure if it is added to docs. Contribution is more than welcome
HTH