File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Threads and Synchronization and the fly likes javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException" Watch "javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException" New topic

javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException

Ashutosh Arya
Ranch Hand

Joined: Oct 07, 2008
Posts: 69

I am getting the below error in an environment where I am having a vertical cluster of servers which are trying to execute a code in parallel (via separate JVM calls).

This code contains

The error which I am getting is:

javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not lock: [dataBaseObject#174]
Impl.JCLLoggerAdapter error ORA-00060: deadlock detected while waiting for resource

It seems that the calls from several JVMs is creating a deadlock as the resource is locked (by above mentioned code to avoid dirty reads or non-repeatable rows).

What is the best possible solution for this scenario to avoid deadlocks?

Thanks in advance.
Martin Vajsar

Joined: Aug 22, 2010
Posts: 3733

Is your database always Oracle? In Oracle, dirty reads are not possible, and non-repeatable reads could be avoided using serializable or read-only transactions (I'm not sure whether it is possible to use read-only transaction with Hibernate, though, and serializable isolation level can bring up problems of its own). On top of that, single queries are always self-consistent. Taking this into consideration could perhaps allow you to modify your logic to avoid explicit locking.

Other than that, the solution to avoid deadlocks is always the same: all clients need to lock objects in the same order. It can be easier said than done, as database locks are generally created on various DML operations. In Oracle the situation is easier compared to some other databases, as locks are never obtained for reading, only for updates (and, of course, for explicit locking, which includes SELECT FOR UPDATE).
I agree. Here's the link:
subject: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException
It's not a secret anymore!