Parallel execution has transaction concurrency problems

Hi !

I defined this process:

I realized, after testing it, that parallel processing wasnt working. Documentation says I must mark async before in true and uncheck exclusive to make it work.

I did that, and I have this error message on camunda log:

14-Oct-2016 10:24:02.981 WARNING [pool-2-thread-3] org.camunda.commons.logging.BaseLogger.logWarn ENGINE-14006 Exception while executing job 7736ad9c-9211-11e6-9585-3052cb7171b3:
 org.camunda.bpm.engine.OptimisticLockingException: ENGINE-03005 Execution of 'UPDATE ExecutionEntity[77365f6f-9211-11e6-9585-3052cb7171b3]' failed. Entity was updated by another transaction concurrently.

Im NOT updating common variables in those jobs. I’m inserting new process variables with different names to avoid concurrency problems. Problem seems to be process itself instead of process variables.

Im executing REST methods in remote servers, so its very important for me to make parallel functionality work.

Thanks in advance

Hi @Maximiliano_Carrizo,

Before we look into that problem in detail, it would be very helpful if you could provide the following information:

  • Camunda Version
  • Type + version of your application server
  • Type + version of your database
  • The stack trace

Thanks,
Johannes

Camunda version: 7.5.0
Application Server: Camunda BPM Platform ( with Tomcat 8 )
Database: Microsoft SQL Server 10.50.1600
Stack Trace:

14-Oct-2016 11:42:40.770 WARNING [pool-2-thread-3] org.camunda.commons.logging.BaseLogger.logWarn ENGINE-14006 Exception while executing job 71728974-921c-11e6-999e-3052cb7171b3:
 org.camunda.bpm.engine.OptimisticLockingException: ENGINE-03005 Execution of 'UPDATE ExecutionEntity[717177f7-921c-11e6-999e-3052cb7171b3]' failed. Entity was updated by another transaction concurrently.
        at org.camunda.bpm.engine.impl.db.EnginePersistenceLogger.concurrentUpdateDbEntityException(EnginePersistenceLogger.java:125)
        at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.handleOptimisticLockingException(DbEntityManager.java:328)
        at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.flushDbOperationManager(DbEntityManager.java:300)
        at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.flush(DbEntityManager.java:283)
        at org.camunda.bpm.engine.impl.interceptor.CommandContext.flushSessions(CommandContext.java:321)
        at org.camunda.bpm.engine.impl.interceptor.CommandContext.close(CommandContext.java:249)
        at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:113)
        at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:66)
        at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30)
        at org.camunda.bpm.engine.impl.jobexecutor.ExecuteJobsRunnable.executeJob(ExecuteJobsRunnable.java:79)
        at org.camunda.bpm.engine.impl.jobexecutor.ExecuteJobsRunnable.run(ExecuteJobsRunnable.java:57)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

Hi @Maximiliano_Carrizo,

I took a look at your concurrency problems. This is expected behavior. What you can do is to set the joining parallel gateway to async. If you’re interested in the details then I recommend you to have look at the Transactions in Processes chapter in the documentation.

If you have any further questions, do not hesitate to ask! Hope that helps.

Best,
Johannes

Hi, Johannes !

I read the documentation and … you are right. So Im creating threads manually to obtain remote services information.

Its a pity, but …

Thanks for your support !

Hi @Maximiliano_Carrizo,

You do not have to create threads manually. I just realized that I gave you an outdated version of the Transaction in Processes chapter. I updated the link given in my previous post. If you’re really interested in what the problem actually is, then you could read the optimistic locking section.

Best,
Johannes

Johannes, I readed your updated documentation… and it does not satisfy me. I don’t want to trap exceptions, and I don’t want to establish a retry policy. I just want to execute in parallel three or more REST services, each one of them in its own task, and collect the results in the end gateway. If I have to code even a single line, I prefer to use threads in one task, join them and … voila !

Best !

1 Like

Hi Maximilliano,

please post your process model on which the OLE appears.

Do you tried to execute your model without the async flags?
Where do you read that you have to unflag the exclusive flag?
What speaks against the retry mechanism?

Best Regards,
Chris

Hi,Zelldon !

Do you tried to execute your model without the async flags?
Yes, and it executes every task in serial mode.
Where do you read that you have to unflag the exclusive flag?
I’ve unflag the exclusive flag to try to make it work in parallel
What speaks against the retry mechanism?
Zelldon… I will explain my business model, to give you visibility:

Every time our final user fills a form, I need to get information from different remote sources, wait for the response of each one of those remote sources, join all responses, and show those responses to the user. Unfortunally, those services are very slow ( after all, Im in Argentina ) … and, if I execute those remote services serialized, our user will die for starvation. This is why I need to use a parallel system to work.

Best !

1 Like

Hello, we have the same trouble and we are looking forward to the solution. We wonder if anyone can help at this topic?