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
- Red Hat JBoss Enterprise Application Platform (EAP)
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.