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.