Database deadlocks caused by lock upgrades
To avoid database deadlocks caused by lock upgrades, we can 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, ensure that 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 the product 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. We 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, as described in Applying access intent policies to beans.
Related:
Access intent policies for EJB 2.x entity beans Concurrency control Use access intent policies for EJB 2.x entity beans Applying access intent policies to beans Access intent -- isolation levels and update locks