If the method that drives the ejbLoad() method is configured to be read-only
but updates are then made within the transaction that loaded the bean's state,
an exception is thrown during invocation of the ejbStore() method, and the
transaction is rolled back. Likewise, the ejbRemove() method cannot succeed
in a transaction that is set as read-only. If an update hint is applied to
methods of entity beans with bean-managed persistence, the same behavior and
exception results. The forwarded exception object contains the message string PMGR1103E:
update instance level read only bean beanNameThis exception
is also thrown if the applied access intent policy cannot be honored because
a finder, ejbSelect, or container-managed relationship (CMR) accessor method
returns an inherently read-only result. The forwarded exception object contains
the message string PMGR1001: No such DataAccessSpec - methodName
The
most common occurrence of this error is when a custom finder that contains
a read-only EJB Query Language (EJB QL) statement is called with an applied
access intent of wsPessimisticUpdate or wsPessimisticUpdate-Exclusive.
These policies require the use of a USE AND KEEP UPDATE LOCKS clause on the
SQL SELECT statement to be executed, but a read-only query cannot support
USE AND KEEP UPDATE LOCKS. Other examples of read-only queries include joins;
the use of ORDER BY, GROUP BY, and DISTINCT keywords.
To eliminate
the exception, edit the EJB query so that it does not return an inherently
read-only result or change the access intent policy being applied.
- If an update access is required, change the applied access intent setting
to wsPessimisticUpdate-WeakestLockAtLoad or wsOptimisticUpdate.
- If update access is not truly required, use wsPessimisticRead or wsOptimisticRead.
- If connection sharing between entity beans is required, use wsPessimisticUpdate-WeakestLockAtLoad or wsPessimisticRead.