+++ This bug was initially created as a clone of Bug #1234592 +++ Description of problem: When using AsyncWorkItemHandler with Oracle, a job can be picked up by two threads when the thread pool size is larger than 1. For queries which use rownum + for update, Hibernate issues not a single query, but breaks this up in two. This allows for the same job being processed by different AvailableJobsExecutor threads: 2015-06-21 12:53:58,489 DEBUG [org.jbpm.executor.impl.AvailableJobsExecutor] (EJB default - 10) Executor Thread org.jbpm.executor.impl.AvailableJobsExecutor@434eb850 Waking Up!!! 2015-06-21 12:53:58,489 DEBUG [org.jbpm.executor.impl.AvailableJobsExecutor] (EJB default - 9) Executor Thread org.jbpm.executor.impl.AvailableJobsExecutor@6d182f77 Waking Up!!! 2015-06-21 12:53:58,490 INFO [stdout] (EJB default - 10) Hibernate: select * from ( select requestinf0_.id...) ) where rownum <= ? 2015-06-21 12:53:58,492 INFO [stdout] (EJB default - 9) Hibernate: select * from ( select requestinf0_.id ...) ) where rownum <= ? 2015-06-21 12:53:58,556 INFO [stdout] (EJB default - 10) Hibernate: select id from RequestInfo where id =? for update 2015-06-21 12:53:58,559 INFO [stdout] (EJB default - 9) Hibernate: select id from RequestInfo where id =? for update This shows that both threads can obtain the same job instance, as outlined in the related Hibernate issue: "Yes it does allow a slight possibility that a row might be updated or locked between the initial select (paging) and the subsequent lock attempt." from https://hibernate.atlassian.net/browse/HHH-1168?focusedCommentId=48846&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-48846
backported to 6.2.x branch: jbpm https://github.com/droolsjbpm/jbpm/commit/6258b2352f1f927484a334b224d66ad6b7728d04 https://github.com/droolsjbpm/jbpm/commit/d5b5bf0a0cfa1c4d07403f849f16f8951faf0b1b
Verified on BPMS 6.1.3 CR1