[jbpm-issues] [JBoss JIRA] Issue Comment Edited: (JBPM-2139) Concurrency problems with the Join node despite lock="pessimistic"
[
https://issues.jboss.org/browse/JBPM-2139?page=com.atlassian.jira.plugin....
]
Alejandro Guizar edited comment on JBPM-2139 at 12/9/10 12:23 PM:
------------------------------------------------------------------
The proposals in this issue were independently developed in the following issues.
* With JBPM-1952, a queue redelivery delay was configured to mitigate locking exceptions
under heavy concurrency conditions.
* In JBPM-2787, the engine ends the concurrent token when it enters the join node, and
checks all children of the parent token have ended when the join executes.
* After JBPM-2790, exclusive jobs lock the process instance pessimistically, instead of
searching for other exclusive jobs for the process instance.
* JBPM-2945 introduced a new job processor based on EJB3, which employs scheduled message
delivery instead of the timer service, and groups messages by process instance.
was (Author: alex.guizar(a)jboss.com):
The proposals in this issue were independently applied in JBPM-1952, JBPM-2790 and
JBPM-2945.
With JBPM-1952, a queue redelivery delay was configured to mitigate locking exceptions
under heavy concurrency conditions.
In JBPM-2787, the engine ends the concurrent token when it enters the join node, and
checks all children of the parent token have ended when the join executes.
After JBPM-2790, exclusive jobs lock the process instance pessimistically, instead of
searching for other exclusive jobs for the process instance.
JBPM-2945 introduced a new job processor based on EJB3, which employs scheduled message
delivery instead of the timer service, and groups messages by process instance.
Concurrency problems with the Join node despite
lock="pessimistic"
------------------------------------------------------------------
Key: JBPM-2139
URL: https://issues.jboss.org/browse/JBPM-2139
Project: jBPM
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.5 GA , jBPM-3.2.5.SP1, jBPM-3.2.5.SP2, jBPM 3.2.6 GA ,
jBPM-3.2.5.SP3, jBPM 3.2.6.SP1, jBPM-3.2.5.SP4, jBPM 3.2.5.SP5
Environment: jbpm 3.2.6, weblogic 9.2.1, oracle 10g
Reporter: George Mournos
Attachments: concurrency.zip
We are evaluating jbpm for concurrency.
We created a test case with a lot of concurrency.
The test process has:
* a fork
* 10 nodes with async="true" and
* a join with lock="pessimistic".
In some of the parallel nodes we get the exception:
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another
transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#121]
We checked that the lock mode is persisted correctly and that the join node actually does
the lock.UPGRADE.
We attach the testcase, the test process definition, and the full stacktrace.
We enforced a stricter locking strategy, namely locking the process instance for as long
as the command executor was working and the test worked ok.
However, we finally dropped this solution because it was creating a lot of row locks and
could lead to transaction timeouts and finally chose another solution.
All of our business logic is in nodes with async="true" and goes through the
jms executor.
We serialize consumption of jms messages belonging to the same process instance by using
a JMS extention of Weblogic, called UnitOfOrder.
WLMessageProducer messageProducer =
(WLMessageProducer)session.createProducer(destination);
messageProducer.setUnitOfOrder(processInstance + "");
This workaround could be useful to people working on weblogic.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira