+++ 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