Database deadlocks caused by lock upgrades
To avoid databse deadlocks caused by lock upgrades, you can change the access intent policy for entity beans from the default of wsPessimisticUpdate-WeakestLockAtLoad to wsPessimisticUpdate or can use an optimistic locking approach.
When accessing data in a database concurrently, an application must be aware of and prepared for database locking that must occur to insure the integrity of the data.
If an entity bean performs a findByPrimaryKey (which by default obtains a 'Read' lock in the database), and the entity bean is updated within the same transaction, then a lock upgrade (to 'Exclusive') occurs.
If this scenario occurs on multiple threads concurrently, then a deadlock can happen. This is because multiple 'Read' locks can be obtained concurrently, but one 'Exclusive' lock can be obtained only when all other locks have been dropped. Because all transactions are attempting the lock upgrade in this scenario, this one 'Exclusive' lock can never be obtained .
To avoid this problem, you can change the access intent policy for the entity bean from the default of wsPessimisticUpdate-WeakestLockAtLoad to wsPessimisticUpdate. This change in access intent enables the application to inform WebSphere and the database that the transaction will update the enterprise bean, and so an 'Update' lock is obtained immediately on the findByPrimaryKey. This avoids the lock upgrade when the update is performed later.
The preferred technique to define access intent policies is to change the access intent for the entire entity bean. You can change the access intent for the findByPrimaryKey method, but this is deprecated in V6.0. (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, to handle rollbacks that could occur. Optimistic locking is really intended for applications that do not expect database contention on a regular basis.
To change the access intent policy for an entity bean, you can use the assembly tool to set the "Default Access Intent for Entities 2.x (Bean Level)" on the Access tab of the EJB Deployment Descriptor, as described in Applying access intent policies to beans.
Related concepts
Access intent policiesConcurrency control
Related tasks
Use access intent policies
Applying access intent policies to beans
Related Reference
Access intent -- isolation levels and update locks
Enterprise beans: Resources for learning