WAS v8.5 > Reference > Troubleshooting tipsAccess intent troubleshooting tips
The following frequently asked questions involving access intent are answered.
Oracle database fails when no access policies are applied
No access intent policies have been applied and the application runs with a DB2 database, but it fails with an Oracle database with the following message: com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: PMGR1001E: No such DataAccessSpec :FindAllCustomers. The backend datastore does not support the SQLStatement needed by this AccessIntent: (pessimistic update-weakestLockAtLoad)(collections: transaction/25) (resource manager prefetch: 0) (AccessIntentImpl@d23690a).
If we have not configured access intent, all of your data is accessed under the default access intent policy (wsPessimisticUpdate-WeakestLockAtLoad). On DB2 the weakest lock is share. On Oracle databases, however, the weakest lock is update; this means the SQL query must contain a FOR UPDATE clause. To avoid this problem, try to apply an access intent policy that supports optimistic concurrency.
Calling a finder method displays an InconsistentAccessIntentException at run time
This can occur when we use method-level access intent policies to apply more control over how a bean instance is loaded. This exception indicates the entity bean was previously loaded in the same transaction. This could happen if you called a multifinder method that returned the bean instance with access intent policy X applied; you are now trying to load the second bean again by calling its findByPrimaryKey method with access intent Y applied. Both methods must have the same access intent policy applied.
Likewise, if the entity was loaded once in the transaction using an access intent policy configured on a finder, you might have called a container-managed relationship (CMR) accessor method that returned the entity bean configured to load using that entity's default access intent.
To avoid this problem, ensure that your code does not load the same bean instance twice within the same transaction with different access intent policies applied. Avoid the use of method-level access intent unless absolutely necessary.
An InconsistentAccessIntentException displays in a container-managed relationship with two beans
There are two beans in a container-managed relationship. The findByPrimaryKey method is called on the first bean and then the getBean2 method is called and a CMR accessor method is called, on the returned instance and an InconsistentAccessIntentException displays.
You are probably using read-ahead. When you loaded the first bean, you caused the second bean to be loaded under the access intent policy applied to the finder method for the first bean. However, we have configured your CMR accessor method from the first bean to the second with a different access intent policy. CMR accessor methods are really finder methods in disguise; the run-time environment behaves as if you were trying to change the access intent for an instance we have already read from persistent store.
To avoid this problem, beans configured in a read-ahead hint are all driven to load with the same access intent policy as the bean to which the read-ahead hint is applied.
A bean with a one-to-many relationship to a second bean displays an error
A bean with a one-to-many relationship to a second bean displays an UpdateCannotProceedWithIntegrityException error when an instance of the second bean is added to the first bean's collection
A bean with a one-to-many relationship to a second bean displays an UpdateCannotProceedWithIntegrityException error when an instance of the second bean is added to the first bean's collection. The first bean has a pessimistic-update intent policy applied.
The second bean probably has a read intent policy applied. When you add the second bean to the first bean's collection, you are not updating the first bean's state, you are implicitly modifying the second bean's state. The second bean contains a foreign key to the first bean, which is modified.
To avoid this problem, ensure that both ends of the relationship have an update intent policy applied if you expect to change the relationship at run time.
Related concepts:
Access intent policies for EJB 2.x entity beans
Concurrency control
Related
Use access intent policies for EJB 2.x entity beans
Reference:
Access intent exceptions
Access intent assembly settings
Access intent -- isolation levels and update locks