7 Replies Latest reply on May 14, 2015 2:00 AM by swiderski.maciej

    Parallel async tasks

    adrianch

      I have a very simple process, it looks similar to this process:

      parallel-process.png

      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.

        • 1. Re: Parallel async tasks
          swiderski.maciej

          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

            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

              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

                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

                  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

                    Thank you Maciej!

                     

                    Now it works as expected.

                     

                    Is it documented somewhere?

                    • 7. Re: Parallel async tasks
                      swiderski.maciej

                      some details are mentioned in jira though not sure if it is added to docs. Contribution is more than welcome

                       

                      HTH