JPA 애플리케이션 문제점 해결
이 정보를 사용하여 JPA(Java™ Persistence API) 애플리케이션에 대한 다양한 알려진 문제점을 찾을 수 있습니다.
프로시저
- JPA thinclient jar를 사용할 때 org.apache.openjpa.* 또는
com.ibm.websphere.persistence.* 클래스에 대해 NoClassDefFoundError를 문제점 해결하십시오.
WebSphere® Application Server 버전 9.0 현재, 사용 가능한 두 개의 JPA thinclient JAR 파일이 있습니다. com.ibm.ws.jpa-2.1.thinclient_9.0.jar: JPA 2.1 스펙 인터페이스뿐 아니라 EclipseLink 클래스 및 인터페이스를 포함합니다. com.ibm.ws.jpa-2.0.thinclient_9.0.jar: JPA 2.0 스펙 인터페이스뿐 아니라 WSJPA 및 OpenJPA 클래스 및 인터페이스를 포함합니다. 버전 9 이전에는 이 jar를 com.ibm.ws.jpa_X.X.jar라고 불렀습니다.
문제점 방지:
애플리케이션이 OpenJPA 또는 WSJPA 특정 클래스나 작동에 의존하고 사용자가 클래스 경로에 com.ibm.ws.jpa-2.1.thinclient_9.0.jar를 추가한 경우, 씬 클라이언트 클래스 경로에서 com.ibm.ws.jpa-2.0.thinclient_9.0.jar를 대신 사용해야 합니다.
gotcha - WebSphere Application Server에서 실행 중인 애플리케이션의 org.apache.openjpa.* 또는
com.ibm.websphere.persistence.* 클래스에 대한 NoClassDefFoundError를 문제점 해결하십시오. WebSphere Application Server 버전 9.0에서, 새 프로파일에 대한 기본 지속성 제공자가 OpenJPA에서 EclipseLink로 변경되었습니다. WebSphere가 EclipseLink를 사용하도록 구성되었을 때 OpenJPA 애플리케이션을 실행하는 경우, OpenJPA 클래스가 JPA 2.1을 사용하도록 구성될 때 서버 런타임에 사용 가능하지 않기 때문에 NoClassDefFoundError가 발생합니다.참고: WebSphere Application Server 버전 8.5.5 마이그레이션 도구를 사용하여 WebSphere Application Server 버전 9.0으로 마이그레이션하는 경우 JPA 레벨이 자동으로 2.0으로 설정되며, 이것은 WebSphere Application Server 버전 8.5.5에서와 동일한 JPA 제공자를 사용합니다.
이 문제를 해결하려면 서버나 클러스터를 JPA 2.0을 사용하도록 재구성하십시오. 이것은 OpenJPA를 기본 지속성 제공자로 설정합니다.
- NoClassDefFoundError: org.apache.openjpa.enhance.PersistenceCapable을 문제점 해결하십시오. OpenJPA를
사용하는 애플리케이션은 엔티티 클래스에서 빌드 시간 향상 도구를 실행할 수 있습니다. OpenJPA 향상을
사용하면 org.apache.openjpa.enhance.PersistenceCapable 같은 클래스에 대한 참조를 컴파일된
클래스에 추가합니다. WebSphere Application Server 버전 9.0에서 새 프로파일에 대한 기본 지속성 제공자가 OpenJPA에서 EclipseLink로 변경되었습니다. WebSphere Application Server이 EclipseLink를 사용하도록 구성될 때 OpenJPA 향상 애플리케이션을 실행하려고 시도하는 경우, OpenJPA 클래스가 JPA 2.1을 사용하도록 구성될 때 서버 런타임에 사용 불가능하기 때문에 NoClassDefFoundError가 발생합니다.참고: WebSphere Application Server 버전 8.5.5 마이그레이션 도구를 사용하여 WebSphere Application Server 버전 9.0으로 마이그레이션하는 경우 JPA 레벨이 자동으로 2.0으로 설정되며, 이것은 WebSphere Application Server 버전 8.5.5에서와 동일한 JPA 제공자를 사용합니다.이 문제를 해결하기 위해 다음을 수행할 수 있습니다.
- 서버나 클러스터를 JPA 2.0을 사용하도록 재구성합니다. 이것은 OpenJPA를 기본 지속성 제공자로 설정합니다.
- 애플리케이션을 다시 컴파일하고 OpenJPA 개선사항 대신 EclipseLink 향상을 사용하여 엔티티를 개선합니다.
- 트랜잭션과 관련된 메시지를 검토하십시오.
특정 조건에서, 다음과 같은 메시지가 로깅될 수 있습니다. Unable to execute {0} on a WebSphere managed transaction. WebSphere does not support direct manipulation of managed transactions.
이 오류는 <non-jta-data-source>로 올바르게 구성되지 않은 데이터 소스에 의해 유발될 수 있습니다. Information Center 주제, 지속성 제공자 및 데이터 소스 연관에서 <non-jta-data-source>로 사용될 데이터 소스 구성 방법을 참조하십시오.
- 런타임에 의해 향상되지 않은 문제점 해결
클래스.
이러한 상황을 진단하는 것은 어렵습니다. 때때로 엔티티 클래스의 OpenJPA 개선사항의 부족까지 문제점을 역추적 할 수 있습니다. 이러한 상황의 예는 엔티티가 지속성 가능이 아닌 경우에 발견될 수 있습니다. 로그에서 다음과 같은 메시지를 찾으십시오. This configuration disallows runtime optimization, but the following listed types were not enhanced at build time or at class load time with a Java agent: "{0}".
이 메시지는 예상 런타임 개선사항이 나열된 엔티티 유형에 발생하지 않았음을 나타냅니다. 대부분의 경우 이 오류는 단지 빌드 시 실패이며 PCEnhancer는 나열된 클래스에서 실행되어야 합니다. 이는 또한 더 관련된 문제점을 표시할 수 있으며, 특히 컨테이너 클래스 로더 변환이 엔티티 개선사항을 수행하도록 예상하는 경우 그렇습니다.
- 닫힌 커서에 대한 문제점 해결 문제. 다음은 로그 org.apache.openjpa.persistence.PersistenceException에 있는 DB2® 예외입니다. :
[ibm][db2][jcc][10120][10898] Invalid operation: result set is closed can be a WebSphere Application Server configuration problem.
기본적으로, 애플리케이션 서버는 2 (CLOSE_CURSORS_AT_COMMIT) 값을 사용하여 resultSetHoldability 사용자 정의 특성을 구성합니다. 이 특성으로 인해 DB2가 트랜잭션 경계에서 resultSet/cursor를 닫습니다. DB2 기본 resultSetHoldability 값의 1 (HOLD_CURSORS_OVER_COMMIT)에도 불구하고, 애플리케이션 서버는 기본값 2를 유지하여 애플리케이션 서버의 이전 릴리스와의 호환성 중단을 방지합니다. 기본값을 변경할 수 있습니다.주의: 이 데이터 소스가 XA 데이터 소스인 경우, 데이터 소스에서 새 사용자 정의 특성을 다음과 같이 정의하십시오. property_name = downgradeHoldCursorsUnderXa 및 boolean value = true.문제점 방지: 8.0에서, DB2 XA 데이터 소스가 사용되는 경우 결과 세트 닫힘 문제점을 극복하기 위해 다음 구성이 필요합니다.
- DB2 버전 9.1 FP4 (APAR IZ18072의 경우) 이상 버전 사용.
- 사용자 정의 특성 name="downgradeHoldCursorsUnderXa", value="true" 및 type="java.lang.Boolean" 추가
- 사용자 정의 특성 name="resultSetHoldability", value="1", type="java.lang.Integer" 추가
- 다중 스레드 EntityManager 사용 방지. 다음 메시지 텍스트와 함께 예외가 발생하는 경우, 부주의로
다중 스레드에 대해 EntityManager 사용을 지원하고 있을 수
있습니다.JPA 스펙에 따라, EntityManagers는 단일 스레드에 의해 사용됨을 의미합니다. 다음과 같은 예외 메시지를 수신할 수 있습니다(이 컨텍스트에서, 브로커 및 EntityManagers는 근본적으로 동일함).이 문제를 처리할 몇 가지 방법이 있습니다.
Multiple concurrent threads attempted to access a single broker. By default brokers are not thread safe; if you require and intend a broker to be accessed by more than one thread, set the openjpa.Multithreaded property to true to override the default behavior.
우수 사례: 애플리케이션 관리(확장) 컨텍스트를 사용하는 경우 get-use-close 패턴을 사용하십시오. EntityManager를 사용한 메소드를 나가기 전에 EntityManager를 닫아야 합니다. EntityManager를 열린 상태로 두면 잘못하여 다른 스레드가 동시에 동일한 EntityManager 인스턴스를 사용하고 시스템 자원을 이용할 수 있습니다.bprac
- @PersistenceContext 어노테이션을 통해 EntityManager 인스턴스를 삽입하여 컨테이너 관리 지속성을 사용하려면 애플리케이션을 변경하십시오(애플리케이션에 대한 프로그래밍 모델이 이 변경에 대해 수정 가능한 경우). 근본적으로 이는 컨테이너가 관리를 수행하도록 지원하여 get-use-close 패턴을 강제 실행합니다.
- 이 예외 텍스트에 문서화된 대로, 빠른 임시 해결책은
openjpa.Multithreaded 특성에서 EntityManagers에 대한 다중 스레드 액세스를 요구하도록
OpenJPA를 구성하는 것입니다. 이 특성을 사용하도록 설정하면
불필요한 오버헤드가 발생할 수 있습니다.
문제점 방지: 서블릿에 대한 인스턴스 변수는 서블릿의 모든 인스턴스에 의해 자동으로 공유됩니다. 서블릿 인스턴스 변수에서 @PersistenceContext 어노테이션을 사용하면 의도하지 않게 동일한 EntityManager에 대한 다중 스레드 액세스가 발생할 수 있습니다. 또한 이러한 방식으로 삽입된 모든 EntityManagers는 애플리케이션이 중지될 때까지 컨테이너에 의해 정리되지 않습니다. 서블릿의 경우, @PersistenceUnit 어노테이션을 사용하여 EntityManagerFactory를 삽입하는 것이 좋습니다. gotcha
- 낙관적 잠금을 사용 중인 경우, 버전 조건을 확인 하십시오.
JPA 아키텍처에서, 지속성 제공자는 버전 특성을 사용하여
지속성 엔티티에 대한 동시성 시맨틱 및 낙관적 잠금을
수행합니다. 예를 들면 다음과 같습니다.
@Entity public class VersionedTimestampEntity { @Id private int id; @Version private java.sql.Timestamp version; .... }
제공자는 데이터베이스에 엔티티가 작성될 때 새 값에 대한 버전 특성을 업데이트합니다. 엔티티 병합 조작 중에 지속성 제공자는 이 버전화된 특성을 실험하여 병합 중인 엔티티가 엔티티의 시간이 경과된(stale) 사본인지 판별합니다. 조작이 시간이 경과된(stale) 버전 조건으로 인해 실패한 경우 OptimisticLockException이 발생합니다. 버전 특성은 다음 유형 중 하나일 수 있습니다.- int
- 정수
- short
- Short
- long
- Long
- Timestamp.
엔티티가 지속되고, 엔티티가 페치되어 플랫폼의 정밀도 창 내에 있는 별도의 지속성 컨텍스트에서 업데이트되는 경우, 지속성 제공자는 낙관적 잠금과 동시성 조건을 발견할 수 없습니다. 그 결과, OptimisticLockException이 처리되지 않고 데이터 무결성이 손상될 수 있습니다.문제점 방지: 버전 특성에 대해 Timestamp 유형을 사용하는 경우 Timestamp 오브젝트를 작성하는 데 사용된 구현 정밀도로 인해 나타날 수 있는 동작을 애플리케이션이 인지해야 합니다. 일반적인 구현은 System.currentTimeMills 메소드를 사용합니다. 이 메소드의 시간 정밀도는 플랫폼에 특정합니다. 예를 들어, 정밀도는 32비트 Windows의 경우 15ms이고 z/OS®의 경우 2ms입니다.gotcha
- 엔티티에 대해 작업 시 데이터베이스 제한조건 위반
문제점 해결.
WebSphere Application Server에 포함된 JPA 제공자는 제한조건 업데이트 관리자를 사용하여 각 엔티티 구성에 기반하여 데이터베이스에 대한 SQL 요청의 순서를 판별합니다. 이 업데이트 관리자는 데이터베이스에 대한 SQL 요청의 순서를 재조정할 수 있습니다. 이는 애플리케이션이 비즈니스 논리를 수행하기 위해 요구되는 엔티티 관리자 조작의 순서를 알아야 하는 것을 완화시켜 주고 기본 일괄처리 지원을 사용하여 데이터베이스 성능을 최적화 합니다.
JPA 제공자가 엔티티 간의 관계에 대한 암시적인 데이터베이스 제한조건이 있음을 가정하지 않으므로, 데이터베이스 제한조건이 있는 경우(예: 외부 키 제한조건) JPA 제공자는 원하는 순서로 SQL문을 발행하지 않을 수 있습니다. 이러한 조건에서 다음과 유사한 예외가 발생할 수 있습니다.com.ibm.db2.jcc.b.SqlException: DB2 SQL error: SQLCODE: -530, SQLSTATE: 23503, SQLERRMC: xxxxxx
이 문제를 처리할 몇 가지 방법이 있습니다.- OpenJPA 제공자는 데이터베이스에서 제한조건 정보를 읽도록 구성되어
지속성 단위에 다음 구성 특성을 추가하여 런타임 시 업데이트 관리자에
적용할 수
있습니다.
<property name="openjpa.jdbc.SchemaFactory" value="native(ForeignKeys=true)" />
- 애플리케이션은 @ForeignKey 어노테이션을 사용하도록 엔티티를 개선하여
JPA 제공자에게 외부 키 제한조건이 있는 관계를 표시할 수 있습니다.
public class Person { @ManyToOne @ForeignKey private Address address; .... }
- OpenJPA 애플리케이션의 경우, 애플리케이션은 지속성 단위에
다음 구성 특성을 추가하여 SQL문의 순서 지정 책임을 수행할 수
있습니다.
<property name="openjpa.jdbc.UpdateManager" value="operation-order" />
이 구성 옵션을 사용하여, JPA 제공자는 엔티티 조작이 요청되었던 동일한 순서로 SQL문을 시작합니다. 애플리케이션은 앤티티 간의 상호 종속성을 인식해야 합니다.
문제점 방지: 이러한 특성의 조합을 사용하도록 포함한 경우에도 상황에 가장 잘 맞는 것만 사용해야 합니다. 이러한 특성의 조합을 사용해야 하는 상황인 경우, openjpa.jdbc.UpdateManager 및 openjpa.jdbc.SchemaFactory 특성 모두를 사용하면 예외를 수정하는 데 필요한 SQL 요청 순서 지정이 발생하지 않을 수 있음을 인식해야 합니다. openjpa.jdbc.UpdateManager 특성에 대한 operation-order 설정은 JPA 제공자에게 SQL 요청이 애플리케이션 내에서 지정된 순서로 수행되도록 함을 나타냅니다. openjpa.jdbc.SchemaFactory 특성을 지정한 경우에도, openjpa.jdbc.UpdateManager명령과 함께, JPA 제공자는 발견된 제한조건(예: 외부 키 제한조건)을 적용하기 위해 자동으로 SQL 요청을 순서 지정하는 대신 애플리케이션에서 지정된 SQL 요청 순서를 적용합니다. openjpa.jdbc.UpdateManager 특성을 지정할 때마다 애플리케이션 내에서 적절한 순서로 SQL 요청을 지정하는 것은 애플리케이션 개발자의 책임입니다.gotcha
- 데이터베이스에서 제한조건 제거.
- OpenJPA 제공자는 데이터베이스에서 제한조건 정보를 읽도록 구성되어
지속성 단위에 다음 구성 특성을 추가하여 런타임 시 업데이트 관리자에
적용할 수
있습니다.
- OpenJPA MappingTool ANT 태스크를 사용하여 문제점 해결.
OpenJPA가 제공하는 MappingTool ANT 태스크는 임시 클래스 로더를 사용하여 JDBC 드라이버 클래스를 로드합니다. 이 임시 클래스 로더는 일부 JDBC 드라이버(예: DB2) 로딩에 문제가 있을 수 있습니다.
MappingTool ANT 태스크 실행 시, 다음과 유사한 오류가 표시될 수 있습니다.
[mappingtool] java.lang.UnsatisfiedLinkError: com/ibm/jvm/Trace.initTrace([Ljava/lang/String;[Ljava/lang/String;)V [mappingtool] at com.ibm.jvm.Trace.initializeTrace(Trace.java:94) [mappingtool] at com.ibm.jvm.Trace.<clinit>(Trace.java:59) [mappingtool] at java.lang.J9VMInternals.initializeImpl(Native Method) [mappingtool] at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) [mappingtool] at java.lang.Class.forNameImpl(Native Method) [mappingtool] at java.lang.Class.forName(Class.java:136) [mappingtool] at com.ibm.db2.jcc.a.o.n(o.java:577) [mappingtool] at com.ibm.db2.jcc.a.o.<clinit>(o.java:329)맵핑 도구를 사용하려면, ANT 태스크에 tmpClassLoader=false 인수를 추가하여 임시 클래스 로더를 사용하지 않도록 설정할 수 있습니다. 다음은 두 개의 예제 ANT 스크립트입니다.
이 예는 문제점을 표시합니다.
<taskdef name="mapping" classname="org.apache.openjpa.jdbc.ant.MappingToolTask" classpathref="jpa.cp"/> . . . <target name="map.broken"> <mapping> <!-- this exhibits the problem --> . . . </mapping> </target>
이 예는 문제점을 방지합니다.
<taskdef name="mapping" classname="org.apache.openjpa.jdbc.ant.MappingToolTask" classpathref="jpa.cp"/> . . . <target name="map.fixed"> <mapping tmpClassLoader="false"> <!-- this will work --> . . . </mapping> </target>
- 불일치 도메인 모델에서 DataCache의 영향
애플리케이션이 불일치 도메인 모델을 지속하고 후에 별도의 지속성 컨텍스트에서 엔티티를 검색하는 경우 검색된 엔티티는 DataCache가 활성인지 여부에 따라 다릅니다.
예를 들어, 데이터베이스에서 단일 외부 키 열에 의해 관리되는 두 엔티티 간의 양방향, 일대일 관계를 고려하십시오. 애플리케이션이 엔티티에서 불일치하게 관계 필드를 설정할 수 있습니다. 그러한 불일치 값이 데이터베이스에 맵핑되는 경우, 데이터베이스 레코드는 단일 외부 키 열이 양방향 관계를 표시하고 DataCache가 활성이지만 DataCache가 불일치 인메모리 엔티티 상태를 캡처하기 때문에만 일치합니다. 따라서, 애플리케이션이 양방향 관계에 관련된 엔티티 쌍을 지속하지만 관계 필드가 불일치 값으로 설정되고 나중에 다른 지속성 컨텍스트에서 검색하면, 양방향 관계는 DataCache가 사용되는지 여부에 따라 불일치 상태로 남거나 일치 상태가 될 수 있습니다.
다중 필드가 동일한 열에 맵핑되지만 다른 값에 설정되는 경우, 불일치 엔티티 상태가 지속되지만 별도의 지속성 컨텍스트에서 일치로 검색되는 또 다른 예입니다. 이 경우, DataCache의 소개는 또한 엔티티가 별도의 지속성 컨텍스트에서 실현되어 DataCache 없이 엔티티가 두 필드 모두에 대해 동일한 값을 유지하여 일치하지 않는 다른 값을 유지하게 됩니다.
우수 사례: 불일치하게 애플리케이션 도메인 모델 채우기 방지. OpenJPA의 경우, 양방향 관계 같은 특정 불일치를 발견하도록 openjpa.InverseManager 특성을 구성할 수도 있습니다. bprac
- Sybase에서 MappingTool 및 @ForeignKey 어노테이션에 대한
문제점 해결.
OpenJPA 맵핑 도구는 Sybase Adaptive Server와 사용하는 경우 ForeignKey 제한조건을 작성할 수 없습니다. 따라서, 외부 키 제한조건은 수동으로 작성해야 합니다.
- DB2 Optim™ pureQuery Runtime 구성 옵션
문제점 해결. WSJPA(WebSphere Application Server JPA) 제공자와 함께 DB2 Optim pureQuery Runtime을 사용 중인 경우, persistence.xml 파일에서 다음 특성을 설정해야 합니다.
<property name="openjpa.Compatibility" value="StrictIdentityValues=true"/>
다른 호환성 옵션(예: ReloadOnDetach=false)을 설정해야 하는 경우, 동일한 특성 명령문의 매개변수로 옵션 둘 다를 persistence.xml 파일에 지정해야 합니다. 예를 들어 다음과 같습니다.
<property name="openjpa.Compatibility" value="StrictIdentityValues=true,ReloadOnDetach=false"/>
문제점 방지: OpenJPA 호환성 특성은 특정 데이터 유형(특히 GregorianCalendar와 같은 날짜 유형)에 대해 OpenJPA가 생성하는 프록시 유형을 제거하지 않습니다. 이 생략으로 인해 직렬화 해제 문제점이 발생할 수 있습니다. 직렬화 해제 문제점이 발생하는 경우 다음 메시지와 유사한 오류 메시지가 발행됩니다.gotcha
Error Message is:org.codehaus.jackson.map.JsonMappingException: Can not construct instance of org.apache.openjpa.util.java$util$GregorianCalendar$proxy, problem: no suitable creator method found at [Source: org.apache.http.conn.EofSensorInputStream@d83fbd5; line: 1, column: 4094]
- z/OS용 DB2 데이터베이스를 사용하는 경우 엔티티에서 시간 관련 유형 속성 문제에 대한
문제점 해결. 엔티티에 시간 관련 유형 속성이 있고, 데이터베이스로 대상이 지정된 해당 맵핑된 열이
호환 가능하지 않은 경우,
특정 상황에서 다음과 같은 예외가
발생할 수 있습니다.
다음과 같은 경우 이러한 예외가 표시될 수 있습니다.org.apache.openjpa.lib.jdbc.ReportingSQLException: THE DATE, TIME, OR TIMESTAMP VALUE 1 IS INVALID. SQLCODE=-18x, SQLSTATE=22007
- 데이터베이스가 z/OS용 DB2를 실행 중입니다.
- 이름 지정된 조회를 사용 중이고 고유 SQL을 사용하여 데이터베이스에 액세스합니다.
- 고유 조회는 시간 관련 필드를 SQL 매개변수로 사용하지만, 조회는 데이터베이스 테이블에 대한 열 정의와 호환 가능하지 않습니다. 호환성에 대한 자세한 정보는 DB2 9.7 Information Center에서 지원 데이터 변환 주제를 참조하십시오.
하위 주제
Logging applications with JPA
Logging supports viewing, tracing, and troubleshooting the runtime behavior of an application. Java™ Persistence API (JPA) provides a flexible logging system that is integrated with the application server to assist you in troubleshooting problems.Troubleshooting JPA deadlocks and transaction timeouts
Database deadlocks and transaction timeouts are the result of contention between two or more clients attempting to access the same database resource. Deadlock is a special case where a circular blocking condition between two or more clients, each blocked by the others, but no one can proceed. Usually these phenomena are not programming errors. They are caused by business logic accessing database resources in a complex and inter-depending fashions.Logging applications with JPA
Logging supports viewing, tracing, and troubleshooting the runtime behavior of an application. Java™ Persistence API (JPA) provides a flexible logging system that is integrated with the application server to assist you in troubleshooting problems.Troubleshooting JPA deadlocks and transaction timeouts
Database deadlocks and transaction timeouts are the result of contention between two or more clients attempting to access the same database resource. Deadlock is a special case where a circular blocking condition between two or more clients, each blocked by the others, but no one can proceed. Usually these phenomena are not programming errors. They are caused by business logic accessing database resources in a complex and inter-depending fashions.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tejb_jpatroubleshoot
파일 이름:tejb_jpatroubleshoot.html