- I have not applied any access intent policies at all. My application runs
just fine 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). Why?
- If you have not configured access intent, all of your data is accessed
under the default access intent policy (wsPessimisticUpdate-WeakestLockAtLoad).
On DB2 databases, the weakest lock is a shared one, and the query runs without
a USE AND KEEP UPDATE LOCKS clause. On Oracle databases, however, the weakest
lock is an update lock; this means that the SQL query must contain a USE AND
KEEP UPDATE LOCKS clause. However, not every SQL statement necessarily supports
USE AND KEEP UPDATE LOCKS; for example, if the query is being run against
multiple tables in a join, USE AND KEEP UPDATE LOCKS is not supported.
To
avoid this problem, try either of the following:
- Modify your SQL query or reconfigure your application so that an update
lock is supported
- Apply an access intent policy that supports optimistic concurrency
- I am calling a finder method and I get an InconsistentAccessIntentException
at run time. Why?
![[Version 5.0.2 and later]](../../v502x.gif)
- This can occur when you use method-level access intent policies to apply
more control over how a bean instance is loaded. This execption indicates
that 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.
- I have two beans in a container-managed relationship. I call findByPrimaryKey()
on the first bean and then call getBean2( ), a CMR accessor method, on the
returned instance. At that point, I get an InconsistentAccessIntentException.
Why?
- 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, you 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 you 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.
- I have a bean with a one-to-many relationship to a second bean. The first
bean has a pessimistic-update intent policy applied. When I try to add an
instance of the second bean to the first bean's collection, I get an UpdateCannotProceedWithIntegrityException.
Why?
- 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.