EJB 컨테이너에 대한 Stateful 세션 Bean 장애 조치(failover)
WebSphere® Application Server를 사용하여 예상치 않는 서버 장애로 제한되지 않는 Stateful 세션 Bean을 사용하는 애플리케이션을 구성할 수 있습니다. 이 제품은 DRS(Data Replication Service) 및 워크로드 관리(WLM) 기능을 사용하므로 Stateful 세션 Bean 장애 조치(failover)를 사용 가능하게 할 수 있습니다.
- 단일 애플리케이션을 제외한 모든 애플리케이션에 대한 장애 조치(failover)를 사용 가능하게 할 수 있습니다. 이 작업을 수행하려면 EJB 컨테이너 레벨에서 장애 조치(failover)를 사용 가능하게 하고 애플리케이션 레벨의 설정을 대체하여 단일 애플리케이션에서는 장애 조치(failover)를 사용 불가능하게 할 수 있습니다.
- 설치되어 있는 단일 애플리케이션에 대한 장애 조치(failover)를 사용 가능하게 할 수 있습니다. 이 작업을 수행하려면 EJB 컨테이너 레벨에서 장애 조치(failover)를 사용 불가능하게 한 다음 애플리케이션 레벨의 설정을 대체하여 단일 애플리케이션에서 장애 조치(failover)를 사용 가능하게 할 수 있습니다.
- 단일 모듈 애플리케이션을 제외한 모든 애플리케이션에 대한 장애 조치(failover)를 사용 가능하게 할 수 있습니다. 이 작업을 수행하려면 EJB 컨테이너 레벨에서 장애 조치(failover)를 사용 가능하게 한 다음 모듈 애플리케이션 레벨의 설정을 대체하여 단일 모듈에서 장애 조치(failover)를 사용 불가능하게 할 수 있습니다.
- 설치되어 있는 EJB 모듈에 대한 장애 조치(failover)를 사용 가능하게 할 수 있습니다. 이 작업을 수행하려면 EJB 모듈 레벨에서 장애 조치(failover)를 사용 불가능하게 한 다음 애플리케이션 레벨의 설정을 대체하여 단일 모듈에서 장애 조치(failover)를 사용 가능하게 할 수 있습니다.
- EJB 컨테이너 패널에서 Stateful 세션 Bean 장애 조치(failover) 사용 또는 사용 안함
- 엔터프라이즈 애플리케이션 패널에서 Stateful 세션 Bean 장애 조치(failover) 사용 또는 사용 안함
- EJB 모듈 패널에서 Stateful 세션 Bean 장애 조치(failover) 사용 또는 사용 안함
장애 조치(failover) 사용할 수 있는 Stateful 세션 Bean 활성화 정책
애플리케이션이 어셈블리되는 동안 Stateful 세션 Bean의 활성화 정책을 지정할 수 있습니다. EJB 컨테이너가 DRS를 사용하여 Stateful 세션 Bean 데이터를 복제하여 장애 조치(failover)를 준비하는 것은 Stateful 세션 Bean이 비활성화되는 경우뿐임을 고려해야 합니다. 기본값인 1회 활성화 활성화 정책으로 Bean을 구성하는 경우, Bean은 Stateful 세션 Bean 장애 조치(failover)에 사용할 수 있도록 즉시 보호되지 않습니다. 따라서 장애 조치(failover)를 사용하는 경우, EJB 컨테이너는 Bean에 구성된 활성화 정책을 무시하고 트랜잭션 경계에서 활성화 활성화 정책을 자동으로 사용합니다. 이렇게 하면 완료되는 트랜잭션에 Bean이 포함될 때마다 Bean이 보호되고 해당 데이터가 복제됩니다.
장애 조치(failover)를 사용할 수 있는 작업의 컨테이너 관리 단위 또는 작업의 Bean 관리 단위의 Stateful 세션 Bean 사용
이 경우, 관련된 "작업 단위"는 트랜잭션 및 활동 세션입니다. 이 제품은 CMT(Container Managed Transaction), BMT(Bean Managed Transaction), CMAS(Container Managed Activity Session) 및 BMAS(Bean Manage Activity Session)에 대한 Stateful 세션 Bean 장애 조치(failover)를 지원합니다. 그러나 컨테이너 관리의 경우, 엔터프라이즈 Bean 메소드 호출에 대한 요청을 전송하여 서버가 연결되지 않는 경우에만 장애 조치(failover)를 준비합니다. 또한 요청을 수신하고 수신확인한 후 서버에 장애가 발생하는 경우에는 장애 조치(failover)를 수행하지 않습니다. 요청 또는 작업 단위 실행 중에 실패가 발생하는 경우, 애플리케이션이 일부 보정 코드를 실행하지 않으면 WLM이 다른 서버로 안전하게 장애 조치(failover)할 수 없습니다. 이 경우, 애플리케이션은 CORBA(Common Object Request Broker Architecture) 예외 및 작업 단위 실행 중에 실패가 발생했기 때문에 투명한 장애 조치(failover)가 발생해서는 안되도록 지정하는 부 코드를 수신하게 됩니다. ORBA 예외 및 부 코드를 확인하고 실패를 보정하도록 애플리케이션을 작성해야 합니다. 보정 코드 실행 후, 애플리케이션은 요청을 재시도할 수 있으며 백업 서버 경로가 존재하면 WLM이 새 요청을 Stateful 세션 Bean의 새 기본 서버로 라우트합니다.
자세한 정보는
Corba 부 코드 주제를 참조하십시오.
자세한 정보는 z/OS®를 제외한 모든 플랫폼의 워크로드 관리 주제를 참조하십시오.
트랜잭션 또는 활동 세션 같은 Bean 관리 작업 단위에 대해서도 마찬가지입니다. 그러나 Bean 관리 작업은 고려해야 하는 새로운 가능성을 소개합니다.
- BMT 또는 활동 세션 호출을 사용하는 Stateful 세션 Bean의 메소드는 SessionContext 오브젝트에서 가져온 UserTransaction에서 메소드를 시작합니다. 이 메소드는 시작된 작업 단위에서 일부 작업을 수행하지만 메소드 호출자로 리턴하기 전에는 트랜잭션 또는 세션을 완료하지 않습니다.
- 메소드 호출을 시작하면 EJB 컨테이너가 메소드로 시작한 작업을 일시중단합니다. 이는 Bean이 Stateful 세션 Bean일 때 Bean 관리 작업 단위에 대한 Enterprise JavaBeans 스펙에서 필요한 조치입니다.
- 클라이언트는 Stateful 세션 Bean에서 여러 가지 다른 메소드를 시작합니다. 메소드를 호출할 때마다 EJB 컨테이너가 일시중단된 트랜잭션을 재개하고 메소드 호출을 디스패치한 다음 호출자로 리턴하기 전에 작업을 다시 일시중단합니다.
- 클라이언트는 1단계에서 시작한 트랜잭션 또는 세션을 완료하는 Stateful 세션 Bean에서 메소드를 호출합니다.
이 시나리오는 작업의 연결 Bean 관리 단위에 대해 설명합니다. 트랜잭션 또는 활동 세션은 두 개 이상의 Stateful 세션 Bean 메소드에 대해 연결됩니다. 애플리케이션이 고정 BMT 또는 BMAS를 사용하며 고정 작업 단위가 완료된 후 다른 연결 작업 단위가 시작되기 전에 서버에 장애가 발생하면 장애 조치(failover)에 성공합니다. 그러나 연결 트랜잭션 또는 활동 세션이 완료되기 전에 서버에 장애가 발생하면 장애 조치(failover)에 실패합니다. 대신 장애 조치(failover) 프로세스에서 새 서버로 Stateful 세션 Bean 요청을 라우트하면 EJB 컨테이너가 활성 연결 트랜잭션 또는 활동 세션 동안 장애가 발생했음을 감지합니다. 이 경우 EJB 컨테이너는 예외를 시작합니다.
이 프로세스는 트랜잭션 또는 활동 세션이 여전히 활성 상태인 경우 컨테이너 관리 및 Bean 관리 작업 단위에 대한 장애 조치(failover)에 실패함을 의미합니다. 유일한 차이점은 Bean 관리 작업 단위에 예외가 발생한다는 점입니다.
애플리케이션 설계 고려사항
- 위의 절에서 설명한 예외가 발생하지 않으려면 Stateful 세션 Bean이 BMT(Bean Managed Transaction)가 아닌 CMT(Container Managed Transaction)를 사용하도록 구성하는 애플리케이션을 작성해야 합니다.
- 장애 조치(failover)를 원하고 애플리케이션이 다른 Stateful 세션 Bean에 대한 참조를 저장하는 HTTP 세션 또는 Stateful 세션 Bean을 작성하는 경우, 관리자는 HTTP 세션 또는 Stateful 세션 Bean이 동일한 DRS(Data Replication Service) 복제 도메인을 사용하도록 구성해야 합니다.
- 동일한 Stateful 세션 Bean에 대한
로컬 참조 및 원격 참조를 사용하지 마십시오.
일반적으로 1차 키가 지정된 Stateful 세션 Bean 인스턴스는 한 번에 하나의 서버에만 존재할 수 있습니다. 장애 조치(failover)를 수행하면 하나의 서버에서 다른 서버로 Bean이 이동할 수 있지만 한 번에 두 개 이상의 서버에 존재할 수는 없습니다. 그러나 동일한 Bean 인스턴스(동일한 1차 키)가 동시에 두 개 이상의 서버에 존재하는 시나리오가 발생하는 경우도 있습니다. 이러한 경우, 각 Bean 사본은 다른 사본의 존재를 인식할 수 없으므로 두 인스턴스 간에 동기화가 수행되지 않아 동일한 상태 데이터를 갖게 됩니다. 그러면 애플리케이션은 예측할 수 없는 결과를 수신합니다.
주의: 이러한 상황이 발생하지 않도록 하려면 장애 조치(failover)를 사용할 수 있는 상태에서 애플리케이션은 절대로 동일한 Stateful 세션 Bean 인스턴스에 대한 로컬(EJBLocalObject) 및 원격(EJBObject) 참조를 모두 가져와서는 안됩니다. - Stateful 세션 Bean에
원격 비동기 메소드를 사용하지 않는 것이 좋습니다.
비동기 메소드가 호출되면, 비동기 메소드 요청은 원격 서버에 의해 대기되고 Future 오브젝트가 클라이언트에 리턴됩니다. 메소드 요청은 Stateful 세션 Bean 인스턴스를 사용해야만 서버에 대기되므로, Future 오브젝트가 해당 서버에 바인딩되고 장애 조치(failover)되지 않습니다. Stateful 세션 Bean에 원격 비동기 메소드를 사용해야 하는 경우, Future 오브젝트 호출이 실패하는 시기를 발견하는 애플리케이션을 작성하고 Stateful 세션 Bean의 동기 호출을 수행하여 비동기 메소드가 시작한 트랜잭션이 완료되었는지 판별하십시오.
-
장애 조치(failover)가 사용 가능 상태일 때는 Stateful 세션 Bean 인스턴스에서 비지속적 EJB 타이머를 참조하지 않는 것이 좋습니다.
Stateful 세션 Bean에 자동 또는 프로그래밍 방식으로 작성된 비지속적 타이머 인스턴스에 대한 핸들이 포함되어 있는 경우, 이 핸들은 Stateful 세션 Bean이 장애 조치(failover)된 후에 유효하지 않은 상태가 되며 핸들을 사용하면 javax.ejb.NoSuchObjectLocalException 예외가 발생합니다. 애플리케이션이 Stateful 세션 Bean에 비지속적 타이머를 참조해야 할 경우, 유효하지 않은 핸들을 처리하는 애플리케이션을 작성하십시오.
주의: Stateful 세션 Bean에 자동 또는 프로그래밍 방식으로 작성된 지속적 타이머에 대한 핸들은 장애 조치(failover)되며 Stateful 세션 Bean이 장애 조치(failover)된 후에 사용할 수 있습니다.
![[z/OS]](../images/ngzos.gif)
z/OS 사용자의 경우만 해당됨
- 다중 하위(servant)
- 피어 다시 시작 및 복구 설정
- Stateful 세션 Bean이 배치되는 클러스터
z/OS 제품에는 제어 영역과 하위(servant) 영역이 있고 WebSphere Application Server, Network Deployment 제품에는 없기 때문에 z/OS에 고유한 하나의 장애 조치(failover) 시나리오가 존재합니다. 이 장애 조치(failover)는 하나의 하위(servant) 영역에서 다른 하위 영역으로의 장애 조치(failover)입니다(제어기의 손실 없이 하위의 손실).
z/OS에서 HFS 기반 기술을 사용하는 경우 해당 기술을 계속 사용하십시오.
비관리 z/OS 서버에서는 하위(servant) 간의 Stateful 세션 Bean 장애 조치(failover)를 사용할 수 있습니다. 장애 조치(failover)는 제공된 비관리 서버의 하위(servant) 사이에서만 발생합니다. 비관리 z/OS 서버에 하위(servant)가 하나만 있으면 장애 조치(failover)가 가능해도 아무런 효과가 없습니다. 장애 조치(failover)가 가능한 비관리 z/OS 서버는 다른 비관리 z/OS 서버로 장애 조치(failover)하지 않습니다. 비관리 서버에서 장애 조치(failover)를 사용하려면 비관리 서버에서 하위(servant)의 장애 조치(failover) 사용을 참조하십시오.