Pessimistic locking and select for update not working as intended on JBoss.

Solution Verified - Updated -


We have some use cases where multiple threads occasionally try to update the same entity simultaneously. To cope with this we lock the transactions. We set a PESSIMISTIC_WRITE lock in the select query. This works almost as we would like it to do. The select queries from the parallel threads are clearly performed in a sequence, but it appears the result returned in the query does not include the changes done in a commit done in a transaction that was holding the write lock when the select query was issued.

We are using Oracle 10g as DB and I can see the following in the logs. "Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes". We have not worried about this earlier as some googling convinced us it is a 'no-issue'. This behaviour can however be seen when turning on hibernate logging. Hibernate does a plain select first and complements it with a select for update later.


  • Red Hat JBoss Fuse Service Works
    • 6.0.0
    • Red Hat JBoss Enterprise Application Platform (EAP)
    • 6.x

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.

Current Customers and Partners

Log in for full access

Log In

New to Red Hat?

Learn more about Red Hat subscriptions

Using a Red Hat product through a public cloud?

How to access this content