액세스 인텐트 예외
다음은 액세스 인텐트 정책의 애플리케이션에 대한 응답으로 발생하는 예외입니다.
- com.ibm.ws.ejbpersistence.utilpm.OptimisticUpdateFailedException
- 로드와 저장 요청 간 다른 트랜잭션 내에서 필드가 변경되기 때문에 낙관적 동시성 하에서 업데이트가 실패하면, OptimisticUpdateFailedException이 발생하며 커미트가 실패합니다.
- com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException
- ejbLoad() 메소드를 구동하는 메소드가 읽기 전용으로 구성되지만 업데이트가 Bean의 상태를 로드하는
트랜잭션 내 작성되면, ejbStore() 메소드의 호출 중 예외가 발생하며 트랜잭션이 롤백됩니다. 마찬가지로,
ejbRemove() 메소드는 읽기 전용으로 설정된 트랜잭션에서 성공할 수 없습니다. 업데이트 힌트가 Bean 관리 지속성이 있는
엔티티 Bean의 메소드에 적용되면, 동일한 동작과 예외가 발생합니다.
전달된 예외 오브젝트는 메시지 문자열 PMGR1103E:
update instance level read only bean beanName을 포함합니다.
파인더, ejbSelect 또는 CMR(Container-Managed Relationship) 액세서 메소드가 원래부터 읽기 전용 결과를 리턴하기 때문에 적용된 액세스 인텐트 정책을 사용할 수 없는 경우에도 이 예외가 발생합니다. 전달된 예외 오브젝트는 메시지 문자열 PMGR1001: No such DataAccessSpec - methodName을 포함합니다.
읽기 전용 EJB QL(EJB Query Language) 명령문을 포함하는 사용자 정의 파인더가 wsPessimisticUpdate 또는 wsPessimisticUpdate-Exclusive의 적용된 액세스 인텐트로 호출되는 경우에 이 오류가 가장 많이 발생합니다. 이 정책을 사용하려면 SQL SELECT 명령문에서 USE AND KEEP UPDATE LOCKS 절을 실행해야 하지만 읽기 전용 조회는 USE AND KEEP UPDATE LOCKS를 지원할 수 없습니다. 읽기 전용 조회의 다른 예는 결합, ORDER BY, GROUP BY 및 DISTINCT 키워드의 사용을 포함합니다.
예외를 제거하려면, 원래 읽기 전용 결과를 리턴하거나 적용된 액세스 인텐트 정책을 변경하지 않도록 EJB 조회를 편집합니다.- 업데이트 액세스가 필요한 경우, 적용된 액세스 인텐트 설정을 wsPessimisticUpdate-WeakestLockAtLoad 또는 wsOptimisticUpdate로 변경합니다.
- 업데이트 액세스가 정말로 필요하지 않은 경우 wsPessimisticRead 또는 wsOptimisticRead를 사용합니다.
- 엔티티 Bean 간 연결 공유가 필요한 경우, wsPessimisticUpdate-WeakestLockAtLoad 또는 wsPessimisticRead를 사용합니다.
- com.ibm.websphere.ejb.container.CollectionCannotBeFurtherAccessed
- 더 이상 범위에 없고 이미 로컬로 버퍼된 내용을 벗어난 경우 지연 콜렉션이 구동되면, CollectionCannotBeFurtherAccessed 예외가 발생합니다.
- com.ibm.ws.exception.RuntimeWarning
- 애플리케이션이 올바르지 않게 구성되면, 애플리케이션이 시작될 때 런타임 경고 예외가 발생하고 시작이 종료됩니다. 확인
기능을 선택하여 애플리케이션 구성의 유효성을 검증할 수 있습니다. 잘못된 구성의 예는 다음을 포함합니다.
- 다른 두 액세스 인텐트 정책으로 구성된 메소드입니다.
- 정의되지 않은 액세스 인텐트 정책으로 구성된 메소드입니다.