EJB 컨테이너

EJB(Enterprise JavaBeans) 컨테이너는 Application Server 내에서 Enterprise Bean에 대한 런타임 환경을 제공합니다. 컨테이너는 애플리케이션 서버 내에서 엔터프라이즈 Bean의 모든 조작을 처리하고 Bean 내의 사용자 작성 비즈니스 논리와 나머지 애플리케이션 서버 환경 사이에서 매개체 역할을 합니다.

단일 컨테이너에 각각 하나 이상의 엔터프라이즈 Bean을 포함한 하나 이상의 EJB 모듈을 설치할 수 있습니다.

EJB 컨테이너는 다음과 같이 엔터프라이즈 Bean에 많은 서비스를 제공합니다.
  • 필요 시 트랜잭션 시작, 커미트 및 롤백
  • 수신 요청에 대해 엔터프라이즈 Bean 인스턴스 풀을 준비 상태로 유지보수 및 비활성 풀과 활성 상태 간 인스턴스 이동, Bean 내의 스레드 조건 충족 보장
  • 엔티티 Bean의 인스턴스 변수와 지속 스토리지에 저장된 해당 데이터 항목의 자동 동기화(가장 중요)

컨테이너는 Bean이 활성 상태로 이동하거나 활성 상태에서 벗어날 때 활성 Bean 인스턴스 세트를 동적으로 유지보수하고 Bean 상태와 지속 스토리지를 동기화하여, 애플리케이션이 애플리케이션 서버 메모리에 Bean 인스턴스를 동시에 보유할 경우보다 더 많은 Bean 인스턴스를 관리할 수 있도록 합니다. 이런 측면에서, EJB 컨테이너는 운영 체제 내의 가상 메모리와 유사한 서비스를 제공합니다.

WebSphere® Application Server는 엔티티 Bean을 통해 데이터베이스 데이터 관리에서 뛰어난 유연성을 제공합니다. 엔티티 EJB Activate at 및 Load at 구성 설정은 엔터프라이즈 Bean의 데이터베이스 행 데이터에서 데이터를 로드하고 캐싱하는 방법과 시기를 지정합니다. 이 구성 설정은 EJB 1.1 스펙에 지정된 대로 엔터프라이즈 Bean 캐싱 옵션 A, B 또는 C를 지정하는 기능을 제공합니다. 어셈블리 도구를 사용하여 이 설정을 구성할 수 있습니다. 어셈블리 도구의 사용 방법에 대해 자세히 알려면 어셈블리 도구 Information Center를 참조하십시오.

트랜잭션 동안, 엔티티 Bean의 상태는 캐시될 수 있습니다. EJB 컨테이너는 A, B 및 C 캐싱 옵션을 지원합니다.
  • A 캐싱 옵션을 사용하면, 애플리케이션 서버는 엔티티 Bean이 단일 컨테이너에서 사용된다고 가정합니다. 해당 Bean의 클라이언트는 해당 컨테이너의 Bean 인스턴스로 요청을 지정해야 합니다. 엔티티 Bean은 기본 데이터베이스에 대한 독점 액세스 권한을 가지고 있으며, 이는 A 캐싱 옵션이 사용된 경우 Bean이 복제되거나 워크로드 관리에 참여할 수 없음을 의미합니다.
    읽기 전용 시나리오를 사용하려는 경우, 제품에서 옵션 A 엔티티 Bean을 대체하는 고성능 변형을 제공합니다. 이 캐싱 옵션을 멀티스레드 읽기 전용이라고 합니다. 표준 옵션 A 작동과 비슷하게 EJB 컨테이너는 계속 Bean을 한 번만 활성화하고 EJB 컨테이너가 활성 인스턴스 캐시의 공간을 요구할 때까지 활성화된 상태로 둡니다. 그러나 EJB 컨테이너는 다음과 같은 작동에서 표준 옵션 A와 다릅니다.
    • EJB 컨테이너는 Bean에 대한 메소드를 호출하는 사용자에 응답하여 정기적으로 지속적 스토리지에서 Bean의 상태를 다시 로드함으로써 Bean이 마지막으로 로드된 이후 지속적 스토리지에 작성되었을 수 있는 변경사항을 파악합니다. Bean의 배치 디스크립터에서 다시 로드 간격 설정을 통해 이 기능을 구성할 수 있습니다. 자세한 정보는 읽기 전용 엔티티 Bean 개발 주제를 참조하십시오.
    • 트랜잭션의 끝에서 EJB 컨테이너가 Bean의 상태를 지속적 저장에 작성하지 않거나 Bean의 ejbStore() 메소드가 호출되지 않습니다.
    • EJB 컨테이너는 동일한 Bean 인스턴스에서 둘 이상의 클라이언트(스레드)로부터의 메소드 호출을 허용합니다. 이 점은 Bean의 내부용 표준 EJB 컴포넌트와 다릅니다. Bean을 개발할 때 이런 측면을 염두에 두어야 하며, Bean의 비즈니스 메소드에 있는 임의의 논리가 전체 thread-safe인지 확인해야 합니다.
  • B 캐싱 옵션을 사용하면 엔티티 Bean은 트랜잭션 전체에서 활성 상태로 남아 있지만, 각 메소드 호출 시작 시 다시 로드됩니다.
  • 옵션 C 캐싱(기본)에서, 엔티티 Bean은 각 트랜잭션이 시작할 때마다 항상 데이터베이스에서 다시 로드됩니다. 클라이언트는 Bean 액세스를 시도할 수 있으며, 이 Bean을 호스트하도록 구성된 모든 컨테이너에서 새 트랜잭션을 시작하도록 시도할 수 있습니다. 엔티티 Bean의 상태는 필요 시 임의의 서버에서 액세스할 수 있는 공유 데이터베이스에서 유지보수된다는 점에서 HTTP 세션에 대해 설명된 세션 클러스터링 기능과 유사합니다.

옵션 A는 트랜잭션 범위 외부에 데이터베이스 데이터를 캐싱하여 최대 엔터프라이즈 Bean 성능을 제공합니다. 일반적으로, 옵션 A는 EJB 컨테이너가 특정 데이터베이스에 독점적으로 액세스하는 경우에만 적용 가능합니다. 그렇지 않으면, 데이터 무결성이 손실됩니다. 옵션 B는 엔티티 EJB 오브젝트 인스턴스의 능동적인 캐싱을 제공하며, 이를 통해 옵션 C보다 성능이 향상되지만 메모리 사용량이 늘어나는 결과를 초래합니다. 옵션 C는 엔티티 EJB의 가장 일반적인 구성으로, 기본 설정입니다.

Activate at 설정은 엔터프라이즈 Bean이 활성화되고 캐시에 배치되는 시점을 지정합니다. 캐시 및 비활성화에서 제거도 이 설정으로 제어됩니다. 유효한 값은 OnceTransaction입니다. Once 설정은 서버 프로세스에서 처음 액세스할 때 Bean이 활성화되고 캐시가 꽉 찰 때와 같이 컨테이너의 자유 재량으로 비활성화됨(및 캐시에서 제거됨)을 나타냅니다. Transaction 설정은 Bean이 트랜잭션 시작 시 활성화되고 트랜잭션 종료 시 비활성됨(및 캐시에서 제거됨)을 나타냅니다. 기본값은 Transaction입니다.

Load at 설정은 Bean이 데이터베이스에서 상태를 로드하는 시점을 지정합니다. 이 특성 값은 컨테이너가 데이터베이스에 대해 독점 또는 공유 액세스 권한을 가지는지를 내포하고 있습니다. 유효한 값은 ActivationTransaction입니다. Activation은 활성화할 때 Bean이 로드됨을 의미하고 컨테이너가 데이터베이스에 대해 독점 액세스 권한을 가짐을 나타냅니다. Transaction은 Bean이 트랜잭션 시작 시 로드됨을 의미하고 컨테이너가 데이터베이스에 대해 공유 액세스 권한을 가짐을 나타냅니다. 기본값은 Transaction입니다. Activate atLoad at 특성의 설정값은 사용되는 커미트 옵션을 제어합니다. 옵션 A(독점 데이터베이스 액세스)의 경우 Activate at = OnceLoad at = Activation을 사용하십시오. 이 옵션은 ejbLoad 함수를 호출하지 않아 데이터베이스 입/출력(I/O)을 줄이지만 Bean 인스턴스에 액세스하는 모든 트랜잭션을 직렬화합니다. 옵션 A는 캐시에서 더 많은 오브젝트를 유지보수하여 메모리 사용을 늘릴 수 있지만, Bean 인스턴스에 다중 트랜잭션이 동시에 액세스하지 않는 경우 더 나은 응답 시간을 제공할 수 있습니다.
중요사항: WebSphere WebSphere Application Server, Network Deployment 및 워크로드 관리 사용을 설정한 경우, 옵션 A를 사용할 수 없습니다.

옵션 B 또는 C를 사용하게 되는 설정을 사용해야 합니다. 옵션 B(공유 데이터베이스 액세스)의 경우 Activate at = OnceLoad at = Transaction을 사용하십시오. 옵션 B는 캐시에서 더 많은 오브젝트를 유지보수하여 메모리 사용을 늘릴 수 있습니다. 그러나 각 트랜잭션은 자체 오브젝트 사본을 작성하므로 주어진 시간에 메모리에 여러 인스턴스 사본(트랜잭션당 하나)이 있을 수 있으며, 트랜잭션마다 데이터베이스에 액세스해야 합니다. 엔터프라이즈 Bean이 ejbActivate 함수를 많이 호출하는 경우, 필수 오브젝트가 이미 캐시에 있으므로 옵션 B를 사용하는 것이 좋습니다. 그렇지 않으면 이 옵션은 옵션 A보다 많은 이점을 제공하지 않습니다. 옵션 C(공유 데이터베이스 액세스)의 경우, Activate at = TransactionLoad at = Transaction을 사용하십시오. 이 옵션은 캐시에 더 적은 오브젝트를 유지보수함으로써 메모리 사용량을 줄일 수 있습니다. 하지만 (트랜잭션마다) 언제든 메모리에 인스턴스의 다중 사본이 있을 수 있습니다. 이 옵션은 동시에 액세스되지만 업데이트되지 않은 엔터프라이즈 Bean 인스턴스에 대한 트랜잭션 경합을 줄일 수 있습니다.

이 제품은 복수 Application Server 사이에서 Stateful 세션 Bean 홈 오브젝트 복제를 지원합니다. 그러나 Stateful 세션 Bean의 특정 인스턴스 복제본은 지원하지 않습니다. 특정 Stateful 세션 Bean의 각 인스턴스는 하나의 애플리케이션 서버에서만 존재할 수 있으며 해당 특정 애플리케이션 서버로의 요청 지정에 의해서만 액세스할 수 있습니다. Stateful 세션 Bean의 상태 정보는 서버 클러스터의 복수 멤버 사이에서 유지보수될 수 없습니다. 그러나 Stateful 세션 Bean 장애 복구를 사용 가능하게 하고 EJB 컨테이너가 메모리에서 메모리로 복제를 사용하도록 구성하면 Stateful 세션 Bean 장애 복구가 클러스터의 다른 서버로 복제되므로 특정 이유로 인해 Stateful 세션 Bean의 기본 서버가 중지되면 백업 서버로 장애 복구가 수행됩니다. Stateful 세션 Bean 장애 복구에 대한 자세한 정보는 EJB 컨테이너의 Stateful 세션 Bean 장애 복구를 참조하십시오.

기본적으로, EJB 컨테이너는 빠른 시작 모드에서 실행됩니다. EJB 컨테이너 시작 논리는 메시지가 게시되기 전에 존재해야 하는 메시지 구동 Bean과 서버 시작 시 처리해야 하는 시작 Bean, 서버 시작 시 초기화되도록 지정하는 EJB 유형을 제외한 모든 EJB 유형의 로드 및 처리를 지연시킵니다.

다른 모든 EJB 초기화는 처음 EJB 유형을 사용할 때까지 지연됩니다. 로컬 인터페이스를 처음 사용하는 경우는 유형에 대해 InitialContext.lookup 메소드를 수행할 때입니다. 원격 인터페이스의 경우에는 EJB 또는 해당 홈에서 첫 번째 메소드를 호출할 때입니다.


주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_ecnt
파일 이름:cejb_ecnt.html