동적 조회 성능 고려사항
동적 조회를 사용하면 편리할 수는 있지만 애플리케이션 성능에 영향을 줄 수도 있습니다.
일반 성능 고려사항
동적 조회에서 다음 요소를 사용하면 애플리케이션 성능이 다소 저하될 수 있습니다.
- 데이터 유형 변환기 및 Java™
메소드
이유: 일반적으로 조회 운영 및 술어는 SQL로 변환되므로 데이터베이스 서버가 수행할 수 있습니다. 조회에 데이터 유형 변환기(예를 들어, RDB 맵핑으로의 EJB용) 또는 Java 메소드가 포함되어 있어도 연결된 조회 술어 및 운영은 애플리케이션 서버의 메모리에서 수행되어야 합니다.
- EJB 참조 리턴을 호출하는 EJB 메소드 및 기준
이유: 이러한 요소를 통합하는 조회는 애플리케이션 서버 메모리에서 EJB 전체 활성화를 트리거합니다. (조회에서 CMP 필드 목록 리턴은 EJB 활성화의 원인이 되지 않습니다.)
애플리케이션 성능에 액세스할 때, 동적 조회는 지속성 관리자와 연결을 공유한다는 사실을 인식해야 합니다. 결과적으로 파인더 메소드, CMR 탐색, 동적 조회를 포함하는 애플리케이션은 이러한 작업을 수행하기 위해 지속성 관리자와 동적 조회 사이에서 단일 공유 연결에 의존합니다.
리턴 콜렉션 크기 제한
- 원격 인터페이스 조회: 원격 인터페이스의 QueryIterator 클래스는 애플리케이션 서버 메모리 내에서
하나의 메소드 호출 경로를 통해 모든 조회 결과를 구체화할 권한을 부여합니다. EJB 조회를 실행하는 데 사용되는 SQL 커서는
해당 호출 완료 때까지 닫혀 있습니다. 이러한 요구사항은 데이터베이스 서버
내에서 병목을 초래할 수 있는 심각한 문제를 안고 있으므로, 잠재적으로
커질 수 있는 결과 콜렉션의 크기를 제한해야 합니다.
- 로컬 인터페이스 조회: 대부분의 경우에서 QueryLocalIterator 오브젝트는
SQL 커서 주위에서 랩퍼로 동작합니다. 수요 주도형이며, 데이터가 점진적으로 리턴되도록 합니다. 데이터베이스의 각 레코드 검색에서
next() 메소드는 iterator에서 호출해야 합니다.
로컬 인터페이스 조회에서 특정 조작을 사용하면 수요 주도형 동작을 대체합니다. 이 경우, 조회 결과는 원격 인터페이스 조회의 결과 콜렉션과 마찬가지로 메모리에서 전체적으로 구체화됩니다. 이러한 경우의 예는 다음과 같습니다.
select e.myBusinessMethod( ) from EmpBean e where e.salary < 50000 order by 1 desc
이 조회가 마지막 결과 콜렉션을 만들어내려면 EJB 메소드 성능이 필요합니다. 결과적으로 데이터베이스의 전체 데이터 세트는 엔티티의 데이터 세트에서 EJB 메소드를 실행할 수 있는 애플리케이션 서버 메모리로 하나의 콜렉션에서 리턴되어야 합니다. 이러한 이유로 EJB 메소드를 호출하는 로컬 인터페이스 조회 운영은 일반적으로 수요 주도형이 아닙니다. 이러한 조회에 대한 리턴 콜렉션 크기를 제어할 수 없습니다.
이들은 수요 주도형이기 때문에 다른 모든 로컬 인터페이스 조회로 리턴 콜렉션 크기를 제어할 수 있습니다. 원하는 리턴 값 번호가 데이터 저장소에서 페치된 다음 조회 루프를 닫기 위해 QueryLocalIterator 오브젝트에서 close() 메소드 호출을 사용할 수 있습니다. 그렇지 않으면 EJB 조회를 실행하는 데 사용되는 SQL 커서는 메모리 또는 트랜잭션 끝에서 전체 결과 세트를 계산하기 전까지 열려 있습니다.