![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
동적 및 배치 EJB 조회 서비스 비교
동적 조회 서비스를 사용하여 배치 시 정의하지 않고 런타임 시 동적으로 구성된 엔티티 Bean에 대해 조회를 빌드하고 실행할 수 있습니다. 동적 조회를 사용하여 런타임 시 정의된 조회의 유연성을 얻고 EJB(Enterprise JavaBeans)-QL(Query Language)의 성능을 활용합니다. EJB-QL 조회의 모든 기능 지원 외에 동적 조회는 표준 정적 조회에 사용 가능하지 않은 기능을 추가합니다. 두 예는 Bean 자체(정적 조회는 현재 하나만 허용)에서 바로 복수 데이터 필드를 선택하는 기능 및 조회에서 직접 비즈니스 메소드 실행입니다.
동적 조회로 보다 효율적이고 자원을 덜 소모한 애플리케이션을 효과적으로 작성할 수 있습니다. 예를 들어, 두 데이터 필드는 조회 결과에서 필요합니다. 표준 EJB-QL 조회는 하나의 데이터 필드만 선택할 수 있기 때문에, 전체 EJB 오브젝트를 선택하고 데이터 액세스 메소드를 통해 리턴된 결과에서 필요한 데이터를 추출해야 하며, CMR(Container Managed Relationships) 경계를 프로세스에서 순회할 수 있습니다. 그러나 동적 조회를 사용하면 추가 CMR 순회 또는 액세서 메소드 없이 조회에서 직접 데이터의 두 부분을 가져올 수 있습니다. 이 원칙은 동적 조회가 성능 이익을 위해 사용될 수 있는지 평가하는 키입니다. CMR 순회 또는 액세서 메소드와 같이 검색해야 하는 비즈니스 로직 양 외에, 검색되어야 하는 데이터 크기를 검토해야 합니다.
리터럴 값이 아닌 조회에서의 매개변수 사용은 다른 성능 고려사항입니다. 대부분의 상황에서, 조회에서 매개변수로 조건 값을 정의한 다음 해당 메커니즘을 통해 이 매개변수를 전달하는 것이 좋습니다. 이 메소드를 사용하여 캐시된 조회 계획이 일치되는 더 많은 기회가 있으며, 처음부터 계획을 구문 분석하고 빌드하지 않아도 됩니다. 예를 들어, "SELECT Object(o) FROM schemaname AS o WHERE o.fieldname LIKE foo"는 executeQuery 메소드에 대한 매개변수로 전달된 값 foo가 있는 "SELECT Object(o) FROM schemaname AS o WHERE o.fieldname LIKE ?1"로 보다 적절하게 표현됩니다. 결과는 다른 문자열 리터럴 조건을 제외하고 동일한 동적 조회 구조의 후속 실행이며, 계획 캐시 히트로 등록됩니다(개선된 "관찰" 성능 전달).
동등한 정적 조회에 대한 직접 대체로서 사용되면, 동적 조회는 정적 변형보다 약 25% 느려집니다. 이 느려짐은 실행 외에 조회에 대한 계획 구문 분석 및 빌드에 필요하기 때문입니다. 정적 변형에서, 배치 시 이 비용이 지불됩니다. 이럼에도 불구하고, 동적 조회 사용을 통해 얻은 추가된 기능, 특히 CMR에서도 단일 조회로 복수 데이터 필드를 선택하는 기능은 성능 개선을 위해 동적 조회를 이용하는 기회를 만듭니다.