nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

potentiality and limits of Activiti Engine

deepyou

Hi all, I've some questions about Potentiality of Activiti Engine. The Problem that i'm going to show you is not for us just a simple technical trouble about Activiti but We need to know if is a Limitation of Activiti Engine or is our Problem

We're going to develop a platform based on a BPMN Engine. Our choise is on Activiti Engine, but in our potentiality tests we have different problems, so we want to know if this problem is just because we're not able to use well the Activiti Engine or because the Activiti Engine has technical limits.

I try to explain main problem, in our OSGi Container (Apache Karaf):

1) It's possible execute two service tasks (or more) that runs concurrently and use the same JavaDelegate Class called with DelegateExpression and injiect in this class a value (one for each istance of service tasks).?

The process is some like this:
[img]https://dl.dropbox.com/u/5368083/bookorder.spring.jpg[/img]

The Service Tasks are setted with:

 activiti:async="true" activiti:exclusive="false"‍

When I deploy the process in my Apache Karaf Container I've the follow exception:

org.activiti.engine.ActivitiOptimisticLockingException: ExecutionEntity[3831] was updated by another transaction concurrently
 at org.activiti.engine.impl.db.DbSqlSession.flushUpdates(DbSqlSession.java:474)[71:org.activiti.engine:5.10.0]
 at org.activiti.engine.impl.db.DbSqlSession.flush(DbSqlSession.java:370)[71:org.activiti.engine:5.10.0]
 at org.activiti.engine.impl.interceptor.CommandContext.flushSessions(CommandContext.java:157)[71:org.activiti.engine:5.10.0]
 at org.activiti.engine.impl.interceptor.CommandContext.close(CommandContext.java:109)[71:org.activiti.engine:5.10.0]
 at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:49)[71:org.activiti.engine:5.10.0]
 at org.activiti.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:33)[71:org.activiti.engine:5.10.0]
 at org.activiti.engine.impl.jobexecutor.ExecuteJobsRunnable.run(ExecuteJobsRunnable.java:46)[71:org.activiti.engine:5.10.0]
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_35]
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_35]
 at java.lang.Thread.run(Thread.java:662)[:1.6.0_35]‍‍‍‍‍‍‍‍‍‍‍

What we want to know is: is possible have a activiti process that run operation in parallel with java class and deploy all process in Apache Karaf OSGi Container?
If is possible can someone suggest a way to follow.
Please help us this is an important technical node for Activiti Engine capability.
Regards.
Gaetano

Find more posts tagged with

Comments

jbarrez

The 'problem' you see is core to the Activiti engine. Indeed, the process you posted here will (sometimes) yield optimistic locking exceptions, if both of them are set to be async=true. This is logical, as there will be two independent threads that try to continue the process. In this case, the solution is of course easy to see, but in general there is no good algorithm to figure out if we can safely join or not.

You can set the exclusive to true, but you'd lose some of the concurrency you've introduced.

trademak

As also discussed via e-mail, there's an opportunity here to leverage the Camel integration with Activiti.
I've created a unit test that shows how you can use SEDA (or JMS) queues in Camel in combination with a Camel service task and a receive task in Activiti to get your use case running.
You can find it here:

https://github.com/Activiti/Activiti/blob/master/modules/activiti-camel/src/test/java/org/activiti/camel/route/AsyncCamelRoute.java

https://github.com/Activiti/Activiti/blob/master/modules/activiti-camel/src/test/java/org/activiti/camel/AsyncProcessTest.java

Best regards,

deepyou

"The parallel gateway runs every task in sequence by default and this is by design".
And this sound's good for BPMN logic but if you need real parallelism the solution with Apache Camel is a elegant and refined solution.

Thanks to all to clear my head about this doubth, Thanks expecially to Tijs Rademakers to all he did for Activiti community, first with his wonderfull book "Activiti in Action" and last but not least for the support that he give every day to the Activiti's users.

Best Regards
Gaetano.

jbarrez

And this sound's good for BPMN logic but if you need real parallelism the solution with Apache Camel is a elegant and refined solution.

Yes, if you need 'true' parallelism. But I've seen very few cases where this was needed from a workflow and BPM engine. There are better frameworks to handle this, in my humble opinion (Camel being one of them). And that is exactly why we have the Camel integration 😉