본 절에서는 Entity Bean의 공통 기능과 각 Bean의 주요 기능에 대해서 설명한다.
3가지 Entity Bean들은 종류에 상관없이 JEUS Entity Bean의 공통 기능을 갖는다.
다음은 EJB 엔진에서 Entity Bean Object가 어떻게 관리되는지 보여준다.
"object management"는 EJB 엔진의 내부적인 Bean Instance Pool과 Connection Pool을 의미한다. 이 Pool들은 각 Bean마다 설정되고 성능 향상과 시스템 자원의 효율적인 관리를 위해 사용된다. 기본적으로 Stateful Session Bean과 비슷하게 동작하므로 본 절에서는 차이점만 언급하고 자세한 내용은 “제7장 Session Bean”을 참고한다.
Entity Bean은 Connection Pool 외에 Entity Cache를 사용한다. Entity EJB가 passivate되려 할 때(passivation timeout이 지났을 때) 그 Bean Instance는 실제로는 바로 passivate되지 않는다(Stateful Session Bean의 경우에는 passivate된다). 대신에 이는 Entity Cache로 전달된다. 이 Cache에서는 모든 passivate된 Entity Bean들이 활성화 상태로 저장되어 있다(즉, 식별이 가능하고, 유효한 상태를 유지한다). 다른 Pool들과 마찬가지로 이 Entity Cache도 런타임 메모리에 유지되고, 따라서 활성화 상태와 passivate 사이의 존재하지 않는 상태에서 Runtime Cache로 작동된다.
Entity Bean이 실제적으로 passivate되는 때는 다음과 같다.
Entity Cache가 사이즈를 줄여야 할 때 passivate가 된다. 새로운 Entity Bean이 Cache로 들어오려 할 때 그 Cache에 이미 passivate된 Bean들이 많이 있을 경우 Cache 내의 Bean들이 강제로 밀려 나간다. 이렇게 강제로 밀려 나간 Entity Bean은 passivate되고 그 상태는 DB에 쓰여지며 그 Instance는 Bean Pool로 반환되거나 Bean Pool이 가득 차 있는 상태라면 버려진다. Cache에 막 들어오려는 Entity Bean은 Cache에 진입하여 결과적으로 강제로 밀려난 Bean Instance의 자리를 차지하게 된다.
Cache 크기는 <persistence-optimize>/<entity-cache-size>로 조절 가능하다. 반드시 설정한 크기만큼 찼을 때 Cache 크기를 줄이는 것은 아나라 힌트로 사용된다. 또한 강제로 밀려나가는 Bean Instance를 선택하는 방법 또한 Cache에 오래 머문 순이 아니다.
이러한 Cache를 사용하면 시간이 많이 소모되는 passivation을 효과적으로 관리할 수 있다는 장점이 있다. Cache를 사용함으로써 passivate된 Entity Bean을 다시 활성화시킬 때 DB에 접근할 필요가 없어지고 Cache에 있는 Instance(만약에 존재하면)를 사용함으로써 해결할 수 있다.
Object Pool의 표준 passivation timeout 값이 시간적인 제약을 관장하는 passivation 값이라면 Entity Cache는 메모리의 제약을 관장하는 passivation 설정값이라고 할 수 있다. 이것이 Entity Cache를 사용하는 주요 동기이다.
주의
Entity Cache 설정은 실제로 "object management"의 설정이 아니라 일반적인 Entity Bean persistence 최적화 설정이다. 이에 대한 자세한 내용은 “8.3. Entity EJB 설정”에서 설명한다.
Entity Bean에 대해 어느 시기에 ejbLoad() 메소드를 호출할 것인지 결정하는 것은 EJB 엔진(컨테이너)이다. 이 메소드는 DB의 상태 정보와 Bean Instance의 런타임 상태 정보를 동기화하기 위해 BMP와 CMP에서 사용한다. 본질적으로 ejbLoad() 메소드는 DB에서 하나의 레코드를 읽고 그 결과를 Bean의 내부 특성 값들에 설정하기 위해 사용된다.
ejbLoad() 메소드는 Entity Bean의 생명주기 동안 적어도 한 번은 호출된다. 어떤 경우에는 Bean Instance의 호출할 때마다 바로 전에 ejbLoad() 메소드를 호출할 필요가 생기기도 한다.
DB에서 Bean의 상태 정보를 읽어야 하는 시나리오는 기본적으로 크게 2가지가 있다.
-
Entity Bean이 여러 개의 EJB 엔진에 걸쳐 클러스터되어 있을 때 그 중 하나의 Bean이 DB의 한 레코드를 변경시킬 수 있다. 즉, 클러스터링된 Entity Bean들이 서로 통신할 수 없기 때문에 특정 Entity Bean Instance의 상태 정보가 가장 최신의 것이라는 것을 보장할 수 없다.
-
어떤 외부 요소(작업자 또는 시스템)가 EJB와 연동되어 있는 DB를 변경할 경우가 있다.
이 시나리오에서 EJB 엔진의 특정 EJB Instance는 DB의 내용을 제대로 반영하지 못한 상태가 된다.
다음 그림은 Entity Bean이 클러스터링되어 있을 때나 외부에서 Bean의 DB 행을 수정했을 때 ejbLoad()가 주기적으로 호출되는 2개의 시나리오이다.
위의 두 시나리오의 상황을 피할 수만 있다면(클러스터링을 사용하지 않고, 어떤 외부 요소도 EJB의 DB 데이터를 변경하지 않는다고 보장한다면) Entity Bean의 ejbLoad() 동작을 최적화할 수 있다.
EXCLUSIVE_ACCESS 엔진 모드를 Bean에 적용하면 최적화가 가능하다. 이 모드를 사용하면, ejbLoad()는 Bean이 Instance화될 때 단 한 번만 호출된다. 이렇게 함으로써 DB의 접근량을 약 50%정도 줄일 수 있다.
다음 그림은 EXCLUSIVE_ACCESS 모드가 사용될 때의 시나리오를 보여주고 있다. EXCLUSIVE_ACCESS는 단지 하나의 Bean이 DB 행을 사용하고 대부분의 ejbLoad()는 최적화된다.
Bean을 클러스터링해야 하거나 외부 요소가 EJB 데이터를 변경시켜야 한다면 SINGLE_OBJECT 또는 MULTIPLE_OBJECT 엔진 모드를 사용해야 한다. 두 모드 중 하나가 사용되면, EJB 엔진은 EJB 클라이언트의 요청이 도착할 때마다 ejbLoad() 메소드를 호출한다. 이렇게 하면 각 Entity Bean의 성능이 저하되지만 모든 상태 정보가 DB에 의해 관리되기 때문에 다른 엔진과 Bean들에게 부하를 분산시킬 수 있다.
다음은 SINGLE_OBJECT와 MULTIPLE_OBJECT 모드의 차이점에 대한 설명이다.
-
SINGLE_OBJECT 에서는 각 EJB 엔진의 단 한 개의 Bean Instance만이 모든 클라이언트의 요청을 처리한다. 즉, 첫 요청이 처리되고 있는 동안 도착한 요청들은 대기하고 있어야 한다.
-
MULTIPLE_OBJECT 모드에서는 이러한 제약이 적용되지 않고 EJB 엔진이 새로운 Entity Bean Instance를 생성하여 새로운 EJB 클라이언트 요청을 처리한다. 즉, MULTIPLE_OBJECT 엔진 모드에서는 새로운 EJB Instance가 할당된다.
다음은 각 엔진 모드를 선택할 때의 장점과 단점을 비교한 표이다.
| 구분 | EXCLUSIVE | SINGLE | MULITPLE |
|---|---|---|---|
클러스터링을 허용하는가? | No | Yes | Yes |
외부 Entity가 DB에 접근 가능한가? | No | Yes | Yes |
DB connection이 효율적으로 사용되는가?(ejbLoad() 호출빈도) | Yes | No | No |
장시간의 트랜잭션의 경우 적당한 옵션을 지원하는가? | No | No | Yes |
하나의 엔진에 적합한 단일 처리의 효과적인 모드는? | Not applicable | Yes | No |
하나의 엔진에서 EJB를 동시에 처리하기 위해 요구되는 효과적인 다중처리 모드는? | Not applicable | No | Yes |
3가지 엔진 모드 중 적합한 모드를 선택하기 위한 기준은 다음과 같다.
-
많은 양의 요청이 Entity Bean에 요청되고, 많은 수의 EJB 엔진들이 설정되어 있다면 SINGLE_OBJECT 모드를 선택하고 엔진들에 Bean을 클러스터링으로 구성한다.
-
많은 양의 요청이 Entity Bean에 요청되지만, 한정된 EJB 엔진이 설정되어 있으면 MULTIPLE_OBJECT 모드를 선택하고 엔진들에 Bean을 클러스터링으로 구성한다.
-
MULTIPLE_OBJECT와 SINGLE_OBJECT를 선택할 때 고려해야 할 중요한 사항 중의 하나는 한 트랜잭션을 수행하기 위해 필요한 총 시간이다. 수행 시간이 많이 소요되는 트랜잭션이라면 당연히 MULTIPLE_OBJECT를 선택할 것을 권장한다.
-
많지 않은 동시 요청이 Entity Bean에 들어온다면 EXCLUSIVE_ACCESS 모드를 선택하고 하나의 EJB 엔진에 Bean을 deploy한다.
EJB 클러스터링에 대한 자세한 정보는 “제6장 EJB 클러스터링”의 설명을 참고한다.
본 절에서는 ejbStore() 호출을 최적화하는 방법에 대해 설명한다.
참고
본 절에서 설명하는 ejbStore() 호출의 최적화 방법은 BMP와 CMP 1.1 Bean들에만 적용되고, CMP 2.0은 다른 방법으로 접근해야 한다.
ejbStore()는 EJB 엔진에 의해 DB의 Bean 상태 정보가 유지되어야 한다고 판단될 때마다 호출된다. 일반적으로 해당 DB로의 접근은 각 트랜잭션의 commit 또는 Bean Instance가 passivate되기 전에 시도된다.
그러나 만약에 트랜잭션의 중간에 Bean의 상태가 바뀌지 않으면 ejbStore()가 호출될 이유가 없다.
JEUS EJB 엔진은 Bean의 상태 변경을 자동적으로 예측할 수 없다. 그러므로 개발자나 deployer는 ejbStore()를 호출하는 시점을 EJB 엔진이 판단할 수 있도록 힌트를 제공해야 한다. 이 힌트는 Non-modifying 메소드들의 목록으로 제공된다. Non-modifying 메소드는 근본적으로 읽기만 허용하는 메소드(getter)로서 Entity Bean의 DB 내부 상태를 변경하지 않는다.
Non-modifying 메소드의 목록을 보고 EJB 엔진은 ejbStore() 메소드를 호출할지 여부를 결정한다. 트랜잭션 중 또는 Bean이 활성화된 상태일 때 Non-modifying 메소드만 실행되면 EJB 엔진은 ejbStore() 호출이 불필요하다고 판단하고 그 과정을 생략한다. 이는 전체적인 성능이 향상됨을 의미한다.
본 절에서는 CMP 1.1/2.0의 주요 기능에 대해서 설명한다.
“8.2.1.2. 엔진 모드 Selection을 통한 ejbLoad() Persistence 최적화”와 “8.2.2.1. Non-modifying 메소드에 의한 ejbStore() Persistence 최적화”에서 ejbLoad()와 ejbStore() 메소드의 호출 시점에 대해서 설명하였다. BMP와 CMP는 ejbLoad()와 ejbStore() 메소드를 사용하기 때문에 BMP와 CMP Entity Bean에만 적용되었다.
본 절에서는 성능향상을 위해 ejbLoad()와 ejbFind() 메소드를 최적화하는 방법에 대해서 설명한다. ejbLoad(), ejbFind()의 구현 방법은 EJB 엔진에 영향을 받기 때문에 CMP Bean(1.1과 2.0 버전)에 국한해서 설명한다. BMP에서 해당 메소드의 구현과 작동 방식은 개발자에 의해 결정된다.
EJB 엔진이 CMP ejbLoad(), ejbFind()를 호출하면 다음과 같은 엔진의 하위 모드를 선택하여 작동 방식을 최적화할 수 있다. 3가지 모드에 대한 자세한 기술적 설명은 하지 않는다.
| 모드 | 설명 |
|---|---|
ejbLoad()를 호출할 때 EJB 엔진이 DB의 Shared Lock을 가질 수 있게 한다. 이 종류의 Lock은 다른 Bean들이 같은 레코드를 읽을 수 있지만 쓰는 것은 금지한다. | |
ejbLoad()를 호출할 때 EJB 엔진이 DB의 Exclusive Lock을 가질 수 있게 한다. 다른 Bean들이 DB에 읽고 쓰는 것을 모두 금지한다. | |
ejbLoad()와 ejbFind()를 호출할 때 EJB 엔진이 DB의 Exclusive Lock을 가질 수 있게 한다. 다른 Bean들이 DB에 읽고 쓰는 것을 모두 금지한다. |
위의 3가지 모드가 사용되어야 하는 상황은 다음과 같다.
-
CMP Bean이 쓰기 작업보다는 읽기 작업을 더 빈번히 수행하면 항상 ReadLocking 모드를 선택한다.
-
CMP Bean이 읽기 보다는 쓰기 작업을 더 많이 수행하면 WriteLocking 모드나 WriteLockingFind 모드를 선택한다.
CMP에서는 엔진 모드와 앞 절에서 설명한 Non-modifying 메소드, 그리고 본 절에서 설명한 엔진 내 하위 모드가 규칙에 맞게 조합되어 설정되어야 한다. 이 모든 파라미터들의 설정 요약은 “8.4. Entity EJB 튜닝”의 설명을 참고한다.
또한 CMP Bean에서는 java.sql.ResultSet의 Fetch Size, EJB 엔진이 기동(Booting)할 때 Caching되어야 하는지의 여부와 EJB Bean Instance가 미리 Instance되어야 할지 등을 결정하는 <init caching> 설정을 할 수 있다.
EJB 엔진이 Bean의 persistence를 관리하는 책임을 가지고 있다면(CMP), Entity Bean Instance 필드와 실제 DB의 테이블과 컬럼들과의 매핑을 선언적으로 정의해주는 방법이 있어야 한다. 또한 DB 소스도 지정해주어야 한다. 이 정보는 EJB XML 환경에 <schema info>로 기술한다.
CMP 1.1의 이 태그에는 EJB 엔진이 CMP 1.1 finder 메소드를 생성할 때 기본적으로 사용될 SQL 문도 포함된다.
경우에 따라 개발자들은 Primary Key 생성 없이 EJB Instance를 생성해야 할 때가 있다. 이 경우 JEUS EJB 엔진이 새로운 EJB Instance에게 할당할 고유의 Primary Key를 생성하도록 설정할 수 있다.
JEUS EJB 엔진은 이 기능을 DB와 연동하여 제공한다. 이러한 자동 Primary Key 생성 기능에 대해 JEUS EJB 엔진은 DB와 연동하여 제공하고, CMP 1.1과 CMP 2.0에 적용된다. 이 기능을 사용하면 Primary Key에 신경쓰지 않고 손쉽게 EJB를 개발할 수 있다.
다음은 자동 Primary Key 생성 기능의 사용 방법과 적용 과정에 대한 설명이다.
-
개발자들은 습관적으로 CMP1.1/CMP2.0을 파라미터 없이 create()를 호출한다. 이것은 create() 메소드가 EJB의 Primary Key가 되는 파라미터를 갖지 않는다는 의미이다.
InitialContext ctx = new InitialContext(); BookHome bHome = (BJookHome) ctx.lookup("bookApp"); Book b = bHome.create(“JEUS EJB Guide”, ”Park Sungho”); // Start using “b”. . . .위의 예제에서 EJB Home인 BookHome을 찾고 EJB Home에서 파라미터가 2개인 create()를 호출한다("JEUS EJB Guide"와 "Park Sungho"). 이 파라미터는 새로운 책의 제목과 저자 이름을 뜻한다. 저자는 다르나 동일한 제목의 책이 있을 수 있기 때문에 이 파라미터들을 Primary Key로 이용하는 것은 적합하지 않다.
이 기능을 지원하기 위해 EJB 엔진은("A") 반드시 고유의 Primary Key를 생성해서 새 책에 할당해야 한다. 그리고 여러 엔진들("B", "C")이 클러스터링된 상태에서도 같은 일이 동시에 발생할 수 있다는 것을 고려해야 한다.
광범위한 클러스터링 중에도 각 엔진들은 고유한 Primary Key를 얻을 수 있어야 하기 때문에 하나의 중앙 저장장치를 필요로 한다. 이 저장장치는 하나의 컬럼과 하나의 데이터로 이루어진 DB로 구현된다.
이 하나의 값은 EJB 엔진과 연동하면서 계속 증가하는 Primary Key Counter(또는 Primary Key Generator)이다. 이 방법으로 DB는 항상 클러스터링된 EJB 엔진이 읽을 수 있는 새롭고 고유한 Primary Key를 유지할 수 있다.
-
Primary Key가 없는 create()가 호출되면, EJB 엔진 "A"는 중앙 저장장치(Primary Key DB)로 접근한다. 이 저장장치로부터 정수로 된 Primary Key를 받아오고 Book Instance에 할당한다.
-
EJB 엔진 "A"는 저장장치에 있는 미리 결정된 값으로 Primary Key를 증가시킨다. 미리 결정된 값(Key Cache Size)은 기본적으로 "1"이다. 그러나 1 이상을 사용할 것을 권장한다("20").
만약 Key Cache Size가 "20"이라면, EJB 엔진 "A"는 "19" (20-1)를 할당한다. 다음에 Primary Key를 읽는 다른 EJB 엔진("B"와 "C")은 가장 최근에 Primary Key를 읽어간 것보다 20이 큰 값을 읽게 된다.
이것은 EJB 엔진 "A"는 19개까지는 외부의 Primary Key 저장장치에 접근 없이 EJB Instance를 생성할 수 있다는 것을 의미한다. 따라서 성능 향상에 큰 기여를 한다. 엔진 "A"는 할당받은 Primary Key의 Counter를 유지함으로써 이 값을 모두 소비했을 때에만 외부에서 새로운 Primary Key를 읽어 온다. 내부적인 Counter는 물론 Primary Key를 생성하는 데 사용된다.
다음은 자동 Primary Key 생성의 특징에 대한 설명이다.
-
Oracle과 MS SQL 서버는 자동으로 Primary Key Sequence를 제공한다. 자동 Primary Key 생성 설정에 대한 자세한 내용은 "Oracle DB에서 Primary Key 생성 설정"과 "MS SQL Server에서 자동 Primary Key 생성 설정"을 참고한다.
-
Non-Oracle과 Non-MS SQL 서버는 직접 Primary Key 테이블을 작성해야 한다. 자세한 내용은 "Other DB의 자동 Primary Key 생성"을 참고한다.
-
자동 Primary Key 생성 기능을 사용하기 위해서는 DB가 반드시 Transaction Isolation Level - TRANSACTION_SERIALIZABLE을 지원해야 한다. 본 안내서에서는 지원한다고 가정한다.
-
Primary Key는 EJB에서 반드시 정의되어야 한다. Primary Key는 반드시 java.lang.Integer 타입이고, 단일 Key여야 하며, EJB DD에 선언되어야 한다.
참고
자동 Primary Key 생성 기능은 반드시 TRANSACTION_SERIALIZABLE(Isolation Level)을 지원해야만 한다. 즉, Oracle, MS SQL 서버 외에는 모두 이 Isolation Level이 지원되는지 확인해야 한다.
다음은 각 DB에 설정하는 방법에 대해 설명한다.
Oracle DB에서 Primary Key 생성 설정
Oracle DB에서 자동 Primary Key 생성은 Oracle에서 사용하는 Sequence 객체를 이용한다. 자동 Primary Key 생성 기능을 설정하기 전에 Sequence 객체가 생성되어 있어야 한다. Sequence 설정에 관련한 내용은 Oracle 문서를 참고한다.
다음은 Oracle DB에서 Primary Key를 생성하는 jeus-ejb-dd.xml의 예이다.
[예 8.1] Oracle DB에서 Primary Key 생성 설정 : <jeus-ejb-dd.xml>
<jeus-ejb-dd>
. . .
<beanlist>
. . .
<jeus-bean>
. . .
<schema-info>
. . .
<data-source-name>MYORACLEDB</data-source-name>
<auto-key-generator>
<generator-type>
Oracle
</generator-type>
<generator-name>
my_generator
</generator-name>
<key-cache-size>
20
</key-cache-size>
</auto-key-generator>
</schema-info>
. . .
</jeus-bean>
. . .
</beanlist>
. . .
</jeus-ejb-dd>
위 예제에서 Primary Key 생성 타입을 "Oracle"로 설정했으며, <generator-name>을 “my_generator”로 하고 <key-cache-size>를 "20"으로 설정했다.
참고
<key-cache-size>는 Oracle의 Sequence 객체의 SEQUENCE INCREMENT 값과 일치해야 한다.
Oracle DB는 <data-source-name>에서 선택된다(여기서는 "MYORACLEDB"가 사용되었는데, JEUSMain.xml의 DB Connection Pool JNDI 이름이다). 설정에 대한 자세한 내용은 "JEUS Server 안내서"를 참고한다.
MS SQL 서버에서 자동 Primary Key 생성 설정
MS SQL 서버에서 자동 Primary Key 생성은 간단하다. MS SQL 서버는 자동으로 고유의 IDENTITY 컬럼에 Primary Key를 유지한다.
다음은 MS SQL 서버에서 자동 Primary Key 생성을 설정한 jeus-ejb-dd.xml의 예이다.
[예 8.2] MS SQL 서버에서 자동 Primary Key 생성 설정 : <jeus-ejb-dd.xml>
<jeus-ejb-dd>
<beanlist>
. . .
<jeus-bean>
. . .
<schema-info>
. . .
<data-source-name>MSSQLDB</data-source-name>
<auto-key-generator>
<generator-type>
MSSQL
</generator-type>
</auto-key-generator>
</schema-inboldfo>
</jeus-bean>
. . .
</beanlist>
</jeus-ejb-dd>
<generator-type>에 "MSSQL"을 입력한다. MS SQL 서버는 <data-source-name>에서 선택된다.
Other DB의 자동 Primary Key 생성 설정
만약 Oracle과 MS SQL 서버 외에 다른 DB를 이용해서 자동 Primary Key를 생성한다면, 다음의 절차를 반드시 지켜야 한다.
-
다음과 같이 DB에 테이블을 하나 생성한다. 테이블은 하나의 컬럼과 하나의 열을 갖고 있어야 하고, 값은 '0'으로 설정되어야 한다.
다음은 Primary Key 값을 관리할 테이블이다.
PrimKeyGeneratorColumn (Primary Key 값이 저장되는 컬럼) Row 1
0 (Primary Key 값의 초기값)
위의 테이블은 다음의 SQL로 생성된다.
CREATE table PrimKeyTable (PrimKeyGeneratorColumn int); INSERT into PrimKeyTable VALUES (0);
-
테이블을 생성하고 jeus-ejb-dd.xml을 다음과 같이 수정한다.
[예 8.3] Other DB의 자동 Primary Key 생성 설정 : <jeus-ejb-dd.xml>
<jeus-ejb-dd> . . . <beanlist> . . . <jeus-bean> . . . <schema-info> . . . <data-source-name>MYDB</data-source-name> <auto-key-generator> <generator-type> USER_KEY_table </generator-type> <generator-name> PrimKeyTable </generator-name> <sequence-column> PrimKeyGeneratorColumn </sequence-column> <key-cache-size> 20 </key-cache-size> </auto-key-generator> </schema-info> . . . </jeus-bean> . . . </beanlist> . . . </jeus-ejb-dd>
위 예제에서 타입은 'USER_KEY_table'이고, 테이블 이름이 'PrimKeyTable'이다. 컬럼 이름은 'PrimKeyGeneratorColumn'이고 Key Cache 크기는 '20'으로 설정했다.
DB를 사용하기 위해서 설정하는 <data-source-name> 태그의 값은 JEUSMain.xml의 DB Connection Pool의 <export-name>과 일치해야 한다.
참고
설정에 대한 자세한 내용은 "JEUS Server 안내서"를 참고한다.
본 절에서는 CMP 2.0의 주요 기능에 대해서 설명한다.
EJB 2.0 스펙에는 DB에 있는 관계(Relationship)를 지원하기 위해 CMP Relationship의 개념이 소개되어 있다. CMP 2.0 Bean들과 이 Relationship들을 사용할 때에는 deployer가 JEUS EJB DD에 추가 정보를 제공해야 한다.
CMP 2.0 Bean은 ejb-jar.xml의 EJB QL 문장과 연계되어 있는 home interface의 findByXXXX() 메소드를 가지고 있어야 한다. JEUS는 표준 EJB QL 언어에 몇 가지 추가 사항을 더 지원한다. 이 추가 지원 사항은 ejb-jar.xml에 사용되거나 Instant EJB QL 요청에 사용될 수 있다.
“8.3.3.3. JEUS EJB QL Extension”에는 위의 예가 포함된 완전한 ejb-jar.xml이 포함되어 있다.
클라이언트 코드 내에서 CMP Bean의 집합을 찾으려면 Bean의 home interface에 선언되어 있는 findByXXXX() 메소드들에 의존할 수 밖에 없다. 이 찾기 방법이 복잡한 경우에는 findByXXXX() 만으로는 부족할 수가 있다.
이러한 경우를 대비하여 JEUS에서는 클라이언트 코드에서 EJB QL select 질의문들을 정의할 수 있는 비표준 인터페이스를 제공한다. 이 인터페이스는 jeus.ejb.Bean.objectbase.EJBInstanceFinder라고 불리며, JEUS EJB DD에 Bean의 Instant QL을 활성화시킨 경우 Entity Bean의 home interface에서 구현한다. 이 인터페이스는 사용자의 EJB QL을 home interface로 넘겨주는 메소드인 findWithInstantQL(String ejbQLString)을 가지고 있다. 이 메소드는 질의에 해당하는 EJB 인터페이스의 java.util.Collection 객체를 반환한다.
이 메소드의 예제는 “8.2.3.3. 자동 Primary Key 생성”을 참고하고, 해당 API에 대한 설명은 “Appendix B. Instant EJB QL API Reference”를 참고한다.