As a result of RHBPMS-997, a custom hibernate dialect has been added to prevent the SELECT ... FOR UPDATE to happen in two different sql statements, which can result in race conditions when selecting a job. With the addition of the priority column in RHBPMS-4778, this custom hibernate dialect is no longer usable as it results in the ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc. errors.

The attached sub-process shows the problem we are facing with 6.4.6+:

1. The first job calls a webservice to initialize a request. If the webservice is not available, the job falls in error and we retry later. After 6 retries, the job is put in ERROR status and a signal is sent to the main process.
2. The second job tries to retrieve the response of the previous request (the first call is asynchronous and the response can take a while). If the response is not available, the job falls in error and we retry later. After 6 retries, the job is put in ERROR status and a signal is sent to the main process.

Obviously we cannot allow the request (1) to be made 2 times... My only workaround now is to downgrade to 6.4.5, as the release 6.4.6 breaks the resolution of RHBPMS-1116.

Limiting the number of threads or using JMS instead is not a solution for the following reasons:

• Thread pool set to one -> does not solve the problem in a cluster with multiple nodes
• only JMS -> not possible with scheduled jobs and retry system