Hide Forgot
using a Resource-Local configured JPA EntityManager, a race condition occurs when multiple clients attempt to claim the same task. The comments section of this bugzilla will include a link to the test case that demonstrates this race condition. using a JTA enabled EntityManager, a race condition continues to occur when multiple clients attempt to claim the same task while other clients simultaneously create new tasks. The race condition is reproducible in a JBoss EAP 5.1 environment. at this time, I do not have a test case that reproduces the problem using JbpmJUnitTestCase. what has been proven to completely resolve race conditions with task functionality is the addition of an optimistic lock on org.jbpm.task.Task.
the following is the URL of the test case that reproduces the race condition in a non-JTA environment : https://github.com/jbride/jbpm/blob/5.2.x-gbd/jbpm-human-task/src/test/java/org/jbpm/task/service/local/sync/BRMS_771742_Test.java
If I understood correctly, you already implemented a fix to this using optimistic locking? Is this available on your branch? If so, could you link me to it, as I tried browsing the commits but couldn't find it immediately.
Hi Kris, here is the url to a Task class with an optimistic lock : https://github.com/jbride/jbpm/blob/5.2.x-gbd/jbpm-human-task/src/main/java/org/jbpm/task/Task.java ... it's implemented similar to your processInstanceInfo / workItemInfo/ sessionInfo classes. I'm of the opinion that we may want to add an optimistic lock to the Task class even if JTA solves race conditions. Seems that there are several requests to have jbpm5 support non-JTA environments in which case support for task concurrency (free of race conditions) is still going to be needed. our performance test findings are that when using a non-JTA enabled TaskServiceSession ..... jbpm5 is extrememly performant. As soon as the switch to JTA enabled TaskServiceSession is made.... performance and scalability drops drastically in a JBoss EAP 5.1.x. some of this performance/scalability/stability degradation can be resolved by tuning arjuna .... which we eventually may decide to do. However, it would be nice to be able to switch between JTA / non-JTA without worrying about race conditions. thanks Kris, jeff
Jeff, This change has been committed in the community, could you check if this solves your issue? Kris
thanks for implementing this Kris. I've tested it out and the new lock works perfectly. I'll close this bug. thanks again! jeff
I had to temporarily roll back this fix in the jbpm 5.2.x branch as it is causing unwanted side effects in the jbpm-console. I'll investigate. See https://bugzilla.redhat.com/show_bug.cgi?id=788489
The fix was reapplied (a while ago) as it was not the cause for the side effects, everything was working fine already.
Update status to ON_QA. Please verify them against ER6.