Use access intent policies to avoid database deadlocks caused by lock upgrades

To avoid databse deadlocks caused by lock upgrades, one 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) then the entity bean is updated within the same transaction, this causes a lock upgrade (to 'Exclusive').

If this scenario occurs on multiple threads concurrently, then a deadlock can happen. This is because multiple 'Read' locks can be obtained concurrently, but only one 'Exclusive' lock can be obtained only when all other locks have been dropped. This one 'Exclusive' lock can never be obtained in this scenario, because all transactions are attempting the lock upgrade.

To avoid this problem, one 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. We can change the access intent for the findByPrimaryKey method, but this is 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, 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, 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.


 

See Also


TARGET NOT FOUND FOR LOOKUP

 

Related Tasks


Using access intent policies
Applying access intent policies to beans

 

See Also


Access intent -- isolation levels and update locks
Enterprise beans: Resources for learning