Database deadlocks caused by lock upgrades


 

+

Search Tips   |   Advanced Search

 

To avoid database deadlocks caused by lock upgrades, change the access intent policy for entity beans from the default of...

wsPessimisticUpdate-WeakestLockAtLoad

...to...

wsPessimisticUpdate

...or we can use an optimistic locking approach.

When concurrently accessing data, verify the application is prepared for database locking that must occur to secure the integrity of the data.

If an entity bean performs a findByPrimaryKey method, which by default obtains a Read lock in the database, and the entity bean is updated within the same transaction, a lock upgrade to Exclusive.

If this scenario occurs concurrently on multiple threads, a deadlock can happen. This is because multiple read locks can be obtained at the same time but one exclusive lock can only be obtained when the other locks are dropped. Since all transactions are attempting the lock upgrade in this scenario, the one exclusive lock cannot be obtained.

To avoid this problem, we can change the access intent policy for the entity bean from the default of wsPessimisticUpdate-WeakestLockAtLoad method to wsPessimisticUpdate method. This change enables the application to inform WAS and the database that the transaction has updated the enterprise bean. The Update lock is immediately obtained on the findByPrimaryKey method. This avoids the lock upgrade when the update is performed at a later time.

The preferred technique to define access intent policies is to change the access intent for the entire entity bean. We can change the access intent for the findByPrimaryKey method, but this was deprecated in V6. You might want to change the access intent for an individual method if, for example, the entity bean is involved in some transactions that are read only.

An alternative technique is to use an optimistic approach, where the findByPrimaryKey method does not hold a read lock, so there is no lock upgrade. However, this requires that the application is coded for this in order to handle rollbacks. Optimistic locking is intended for applications that do not expect database contention on a regular basis.

To change the access intent policy for an entity bean, we can use the assembly tool to set the bean level.



 

Related concepts

Access intent policies
Concurrency control

 

Related tasks

Use access intent policies
Apply access intent policies to beans

 

Related

Access intent -- isolation levels and update locks