싱글톤 세션 Bean 개발
EJB(Enterprise JavaBeans) 3.1 스펙이 소개하는 싱글톤 세션 Bean에 대한 Bean 구현 클래스를 작성하십시오. EJB 컨테이너는 싱글톤 세션 Bean 인스턴스를 하나만 초기화하며 해당 인스턴스는 모든 클라이언트에서 공유됩니다. 모든 클라이언트가 단일 인스턴스를 공유하기 때문에 싱글톤 세션 Bean에는 특별한 라이프사이클 및 동시성 시맨틱이 있습니다.
시작하기 전에
이 태스크 정보
public interface Configuration {
Object get(String name);
void set(String name, Object value);
}
@Singleton
public class ConfigurationBean implements Configuration {
private Map<String, Object> settings = new HashMap<String, Object>();
public Object get(String name) {
return settings.get(name);
}
public void set(String name, Object value) {
settings.put(name,value);
}
}
기타 엔터프라이즈 Bean 유형과 마찬가지로 어노테이션을 사용하는 것보다 배치 디스크립터에서 싱글톤 세션 Bean에 대한 메타데이터를 선언할 수도 있습니다. 예를 들면,
<?xml version="1.0"?>
<ejb-jar
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
version="3.1"
>
<enterprise-beans>
<ejb-name>ConfigurationBean</ejb-name>
<business-local>com.ibm.example.Configuration</business-local>
<ejb-class>com.ibm.example.ConfigurationBean</ejb-class>
<session-type>Singleton</session-type>
</enterprise-beans>
</ejb-jar>
프로시저
- 트랜잭션 컨텍스트 설정을 위한 옵션과 관련되는 방법을
이해해서 초기화 및 제거 메소드를 코드화하십시오. 초기화 중 인스턴스가 작성되고
종속성 주입이 발생하며 PostConstruct 라이프사이클
인터셉터 콜백이 시작됩니다. PreDestroy 라이프사이클 인터셉터
콜백은 그의 포함하는 애플리케이션이 중지될 때 싱글톤
세션 Bean에 대해 시작됩니다.
PostConstruct 및 PreDestroy 라이프사이클 인터셉터 콜백 동안 트랜잭션 활동을 완료하는 것이 유용할 수 있습니다. 이러한 이유로 싱글톤 세션 Bean 라이프사이클 인터셉터 콜백에는 잘 정의된 트랜잭션 컨텍스트가 있습니다. 다음 트랜잭션 컨텍스트 값은 @Timeout 메소드와 비슷합니다. REQUIRED(기본값), REQUIRES_NEW, NOT_SUPPORTED만이 사용될 수 있으며, REQUIRED는 REQUIRES_NEW로 변환됩니다.
트랜잭션 속성은 Bean 클래스의 라이프사이클 인터셉터 메소드에서 지정될 때만 인식됩니다. 동일한 트랜잭션 컨텍스트가 모든 라이프사이클 인터셉터에 사용됩니다. 다음 예제는 PostConstruct 및 PreDestroy 라이프사이클 인터셉터 콜백에 지정한 트랜잭션 속성으로 싱글톤 세션 Bean을 설명합니다.
@Singleton public class ConfigurationBean implements Configuration { @PostConstruct @TransactionAttribute(REQUIRED) // the default; specified for illustration public void initialize() { // ... } @PreDestroy @TransactionAttribute(NOT_SUPPORTED) public void destroy() { // ... } // ... }
어노테이션을 사용하는 대신 XML 배치 디스크립터를 사용하여 동일한 메타데이터를 지정할 수 있습니다. XML 배치 디스크립터에 트랜잭션 속성을 지정하는 경우 @TransactionAttribute 어노테이션에서 얻은 메타데이터는 무시됩니다. 다음 예제는 XML 배치 디스크립터를 사용하여 이전 예제와 동일한 메타데이터를 지정합니다.
<assembly-descriptor> <container-transaction> <method> <ejb-name>ConfigurationBean</ejb-name> <method-name>initialize</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> <container-transaction> <method> <ejb-name>ConfigurationBean</ejb-name> <method-name>destroy</method-name> </method> <trans-attribute>NotSupported</trans-attribute> </container-transaction> </assembly-descriptor>
- 별도로 지정되지 않은 경우, 싱글톤 세션 Bean 인스턴스는
일반적으로 기타 세션 Bean과 동일한 클라이언트 보기 중
하나를 통해 Bean이 우선 사용될 때 초기화됩니다. @Startup 어노테이션 또는 해당 XML 배치 디스크립터를
사용하여 Bean을 시작 Bean으로 표시하십시오. 싱글톤 Bean을
시작 Bean으로 표시하는 것은 EJB 컨테이너가 실행할 애플리케이션에 작성된
모든 외부 클라이언트 요청을 지원하기 전에 PostConstruct 메소드를
실행해야 함을 의미합니다. 싱글톤 Bean의 PostConstruct 메소드는
EJB 타이머를 작성하고 JMS 큐 또는 토픽에 메시지를 추가하며 비동기
EJB 메소드를 호출하거나 EJB를 호출하는 기타 비동기 메커니즘을 초기화할 수 있습니다. 그러나 교착 상태를 피하기 위해 PostConstruct 메소드는
EJB 타이머가 실행되고 메시지 구동 Bean 메소드가 호출되거나
비동기 EJB 메소드가 완료될 때까지 대기하지 말아야 합니다.
애플리케이션 개발자는 이들 시작 싱글톤 인스턴스의 PostConstruct 메소드에 비즈니스 로직을 배치하여 캐시 사전 로드 또는 애플리케이션 내에서 비동기 작업 시작 같이 컨테이너가 시작하는 모든 클라이언트 작업 전에 수행되어야 하는 태스크를 완료할 수 있습니다.
다음 예제는 시작 초기화를 갖는 싱글톤 세션 Bean을 설명합니다.
@Singleton @Startup public class ConfigurationBean implements Configuration { @PostConstruct public void initialize() { // 1. Create the database table if it does not exist. // 2. Initialize settings from the database table. // 3. Load a cache. // 4. Initiate asynchronous work (for example, work to a messaging queue or to // calls to asynchronous session bean methods. } // ... }
어노테이션을 사용하는 대신 XML 배치 디스크립터를 사용하여 동일한 메타데이터를 지정할 수 있습니다. 이 싱글톤 Bean을 시작 싱글톤으로 표시하려면 true를 지정하십시오. 반대로, false를 지정하십시오. 그러면 @Startup 어노테이션이 클래스 파일에 존재하는 경우에 대체됩니다.
<session> <ejb-name>ConfigurationBean</ejb-name> <init-on-startup>true</init-on-startup> </session>
- 싱글톤 세션 Bean의 초기화 메소드에 다른 싱글톤
세션 Bean에 대한 내부 종속성이 있는지 여부를
판별하십시오.
내부 종속성이 있는 경우 종속성 메타데이터를 사용하여 종속성을 명시하십시오. 컨테이너는 종속성 Bean을 초기화하기 전에 종속성 싱글톤 Bean이 초기화되고 종속성 Bean을 제거한 후에 종속성 싱글톤 Bean이 제거되는지 확인합니다. 다음 예제는 종속성 메타데이터를 갖는 싱글톤 세션 Bean을 설명합니다.
@Singleton public class DatabaseBean { @PostConstruct public void initialize() { // Create database tables. } } @Singleton @DependsOn({"DatabaseBean"}) public class ConfigurationBean implements Configuration { @PostConstruct public void initialize() { // Initialize settings from a database table. } // ... }
또한, ejb 링크 module.jar#bean 구문을 사용하여 크로스 모듈 종속성을 작성할 수 있습니다. 순환 종속성은 지원되지 않으며, 애플리케이션이 실패하게 만듭니다.
어노테이션을 사용하는 대신 XML 배치 디스크립터를 사용하여 동일한 메타데이터를 지정할 수 있습니다. XML 배치 디스크립터에 종속성 메타데이터를 지정하는 경우 @DependsOn 어노테이션의 메타데이터는 무시됩니다.
<session> <ejb-name>ConfigurationBean</ejb-name> <depends-on> <ejb-name>DatabaseBean</ejb-name> </depends-on> </session>
- 컨테이너 관리 동시성 또는 Bean 관리 동시성을
사용할지 여부를 결정하십시오. @Lock 및 @AccessTimeout 어노테이션은
Bean 관리 동시성을 사용할 때 적용 불가능합니다.
싱글톤 세션 Bean 클래스에만 @ConcurrencyManagement 어노테이션을 구현할 수 있습니다. 확장한 클래스 또는 클래스 상속 트리의 더 높은 클래스에서 사용할 수 없습니다.
다음 코드 예는 Bean 관리 동시성을 갖는 싱글톤을 설명합니다.@Singleton @ConcurrencyManagement(BEAN) public class ConfigurationBean implements Configuration { private Map<String, Object> settings = new HashMap<String, Object>(); synchronized public Object get(String name) { return settings.get(name); } synchronized public void set(String name, Object value) { settings.put(name, value); } }
어노테이션을 사용하는 대신 XML 배치 디스크립터를 사용하여 동일한 메타데이터를 지정할 수 있습니다. 메타데이터가 XML 배치 디스크립터에 지정되고 @ConcurrencyManagement 어노테이션을 사용하는 경우 해당 값이 일치해야 하고, 그렇지 않으면 애플리케이션이 실패합니다. 다음 예제는 XML 배치 디스크립터를 사용하여 이전 예제와 동일한 메타데이터를 지정합니다.
<session> <ejb-name>ConfigurationBean</ejb-name> <concurrency-management-type>Bean</concurrency-management-type> </session>
컨테이너는 호출된 각 메소드에 대한 잠금을 수행하지 않습니다. 대신, 실제 Bean이 필수인 잠금을 담당합니다. 예에서는 Bean 제공자가 동기화된 키워드를 사용하여 메소드를 구현할 것을 선택했습니다. 이것은 Bean 관리 동시성을 갖는 싱글톤 세션 Bean에 대해 지원되지만, EJB 컴포넌트 유형의 경우에는 지원되지 않습니다. Bean 제공자가 동기화된 키워드를 사용하여 동시성을 제공하기 위해 필수는 아닙니다. 예를 들어, Bean 제공자는 JDK 5 이상에서 발견되는 java.util.concurrent.locks.ReentrantReadWriteLock 클래스를 사용할 수 있습니다.
컨테이너 관리 동시성에 대해 EJB 3.1 스펙이 요청하는 잠금 시맨틱은 java.util.concurrent.locks.ReentrantReadWriteLock 클래스의 동작과 일치합니다.
- 컨테이너 관리 동시성을 사용하는 경우 @Lock 표기법을
사용하여 메소드의 동시성을 관리하십시오. 다음 코드 예제는 컨테이너 관리 동시성을 갖는 싱글톤을 설명합니다.
@Singleton public class ConfigurationBean implements Configuration { private Map<String, Object> settings = new HashMap<String, Object>(); @Lock(READ) public Object get(String name) { return settings.get(name); } public void set(String name, Object value) { settings.put(name, value); } }
어노테이션을 사용하는 대신 XML 배치 디스크립터를 사용하여 동일한 메타데이터를 지정할 수 있습니다. 메타데이터가 XML 배치 디스크립터 및 @Lock 어노테이션 모두에 지정된 경우 @Lock 어노테이션에서 얻은 메타데이터는 무시됩니다. 다음 예제는 XML 배치 디스크립터를 사용하여 이전 예제와 동일한 메타데이터를 지정합니다.
<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>get</method-name> </method> <lock>Read</lock> </concurrent-method> </session>
예는 또한 @Lock(READ)를 갖는 메소드가 시작될 때 컨테이너가 읽기 잠금을 확보해야 함을 표시하기 위해 해당 메소드 어노테이션 작성을 설명합니다. 메소드가 @Lock으로 어노테이션 작성될 때 클래스 레벨에 지정된 @Lock 어노테이션을 대체합니다. 클래스 레벨에 @Lock 어노테이션이 없는 경우 기본값은 쓰기 잠금입니다. 예에서 메소드의 @Lock(READ)은 클래스 레벨의 기본 쓰기 잠금을 대체합니다. 메소드가 메소드 레벨에서 어노테이션 작성되지 않고 클래스 레벨에 어노테이션이 없는 경우 쓰기 잠금의 기본값이 컨테이너로 사용됩니다.
대부분의 메소드에 읽기 잠금이 필요하기 때문에 클래스 레벨에서 @Lock(READ)을 사용하여 해당 클래스의 모든 비즈니스 메소드가 읽기 잠금을 얻기 위한 컨테이너가 필요하다는 것을 표시하십시오. 쓰기 잠금이 필요한 메소드의 경우 클래스 레벨에 지정된 읽기 잠금을 대체하는 것을 표시하도록 해당 메소드를 @Lock(WRITE)으로 어노테이션하십시오.
다음 예는 이 기술을 설명합니다.
@Singleton @Lock(READ) public class ConfigurationBean implements Configuration { private Map<String, Object> settings = new HashMap<String, Object>(); public Object get(String name) { return settings.get(name); } @Lock(WRITE) public void set(String name, Object value) { settings.put(name, value); } }
@Lock 어노테이션은 @Lock 어노테이션과 동일한 클래스에서 선언되는 메소드에만 적용됩니다. 주어진 클래스에 대해 @Lock에 대한 메타데이터는 클래스 상속 트리의 더 높은 클래스에서 상속될 수 없습니다. 클래스 레벨에서 어노테이션을 사용하는 대신 모든 메소드와 일치하는 특수 메소드-이름 *를 사용하여 동일한 메타데이터를 XML 배치 디스크립터에 지정할 수 있습니다.
- 컨테이너 관리 동시성을 사용하는 경우 @AccessTimeout
표기법을 사용하여 메소드가 잠금에 부여되는 대기 시간을
제한하십시오. 다음 코드 예제는
동시 액세스 제한시간을 설명합니다.
@Singleton public class ConfigurationBean implements Configuration { @Lock(READ) @AccessTimeout(1000) public Object get(String name) { // query the database } public void set(String name, Object value) { // update the database } }
어노테이션이 제공되지 않으면, 기본적으로 메소드는 잠금이 부여될 때까지 대기합니다. 잠금이 부여될 때까지 클라이언트가 대기하는 데 제한시간이 없습니다. 클래스 레벨에서 코드화된 것이 없기 때문에 클래스의 모든 메소드에 부여되는 잠금에 대해 대기 시간제한이 없습니다. @AccessTimeout 어노테이션이 사용되고 컨테이너가 지정된 제한 시간 내에 잠금을 부여할 수 없는 경우 javax.ejb.ConcurrentAccessTimeoutException이 클라이언트에 발생합니다. @AccessTimeout 어노테이션은 @AccessTimeout 어노테이션과 동일한 클래스에서 선언되는 메소드에만 적용됩니다. 주어진 클래스에 대해 @AccessTimeout 어노테이션에 대한 메타데이터는 클래스 상속 트리의 더 높은 클래스에서 상속될 수 없습니다.
@Lock 어노테이션과 같이 XML 배치 디스크립터를 사용하여 @AccessTimeout 어노테이션을 지정할 수도 있고, XML 배치 디스크립터를 사용하는 경우 @AccessTimeout 어노테이션의 메타데이터는 무시됩니다. 다음 예제는 XML 배치 디스크립터를 사용하여 이전 예제와 동일한 메타데이터를 지정합니다.
<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>get</method-name> </method> <lock>Read</lock> <access-timeout> <timeout>1000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> </session>
- 동시성 methodType의 XML 코딩은 컨테이너 트랜잭션 메소드 요소에
대해 XML을 작성하기 위해 EJB 스펙에 아웃라인된 세 가지의
스타일을 따른다는 것을 인지하는 것이 중요합니다.
lock 및 access-timeout 요소는 모두 선택사항이라는 것을 기억하십시오. 세 스타일은 다음과 같이 선언됩니다.
스타일 1은 특수 메소드 이름 *를 사용하여 잠금 유형, 액세스 제한시간 값 또는 그 둘 다를 지정된 Bean에 대한 모든 비즈니스 메소드에 적용합니다.
<!-- Example: Style 1 --> <concurrent-method> <method> <method-name>*</method-name> </method> <lock>Read</lock> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method>
스타일 2는 특정 이름을 가진 비즈니스 메소드에 대해 참조하고 이를 지정된 잠금 유형, 액세스 시간 제한 값 또는 그 둘 다를 지정하는 데 사용됩니다. 메소드 이름이 오버로드(다중 메소드에 동일한 이름의 다른 메소드 서명이 있음)되는 경우 이 이름의 모든 메소드에 지정된 잠금 유형, 액세스 제한시간 값 또는 둘 다가 있습니다. 스타일 2가 스타일 1에 우선합니다.
<!-- Example: Style 2 --> <concurrent-method> <method> <method-name>businessMethod</method-name> </method> <lock>Read</lock> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method>
스타일 3은 주어진 메소드 이름과 일치하고 나열된 메소드 매개변수와 일치하는 메소드 서명을 가진 다른 메소드를 참조하는 데 사용됩니다. 스타일 3이 스타일 1 및 스타일 2 모두에 우선합니다.
<!-- Example: Style 3 --> <concurrent-method> <method> <method-name>businessMethod</method-name> <method-params> <method-param>long</method-param> <method-param>int</method-param> </method-params> </method> <lock>Read</lock> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method>
스타일 1 XML이 잠금 유형을 정의하는 데 사용되는 경우 Bean의 모든 @Lock 어노테이션이 무시됩니다. 액세스 제한시간의 경우에도 마찬가지입니다. 스타일 1 XML이 액세스 제한시간 값을 정의하는 데 사용되는 경우 Bean의 모든 @AccessTimeout 어노테이션이 무시됩니다.
- 각각에 대한 해당 XML 배치 디스크립터 코드처럼 @Lock
및 @AccessTimeout 어노테이션이 서로 개별적으로 취급되는
것을 이해하는 것이 중요합니다.
이 개념에 대한 구현에는 여러 가지 이점이 있습니다. 잠금 유형과 액세스 제한시간의 이 분리는 잠금 유형을 알 필요 없이 블랙박스 애플리케이션 코드에 부정적인 영향을 주지 않도록 막는 데 도움이 됩니다. 잠금 유형 값을 안전하게 남기고 사용자 환경의 필요성에 맞고 가능한 교착 상태 상황이나 다른 동시성 문제를 피하기 위해서 액세스 제한시간 값만 조정할 수 있습니다.
실행 중인 EJB 애플리케이션을 제공하는 벤더가 있고 시스템이 느려져서 계속 제한시간을 초과하는 시나리오를 고려하십시오. 교착 상태 상황을 야기한다는 걱정에 대해 잠금 논리를 변경하려고 하지 않지만 제한시간 한계는 수정하려고 합니다. 배치 디스크립터를 편집해서 수정하려는 메소드에 필요한 액세스 제한시간 값을 지정할 수 있습니다.다음 예는 Bean 구현에서 메소드 레벨 @Lock(READ) 어노테이션만을 지정하고 선택적 잠금 요소를 제공하지 않고 access-timeout 요소를 2,000 밀리초가 되도록 지정하기 위한 XML을 구성하기 위해 스타일 2를 사용하는 방법을 보여줍니다. 결과는 2,000 밀리초의 액세스 제한시간을 갖는 읽기 잠금을 갖는 메소드입니다.
@Singleton public class ConfigurationBean implements Configuration { @Lock(READ) public Object businessMethod(long value) { // ... } // ... }
마찬가지로, 클래스 레벨 잠금 어노테이션을 사용하여 다음 예제에 표시된 것처럼 스타일 2, 스타일 3 또는 둘 다를 사용하여 XML에 원하는 액세스 제한시간 값을 지정할 수 있습니다.<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>businessMethod</method-name> </method> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> </session>
@Singleton @Lock(READ) public class ConfigurationBean implements Configuration { public Object businessMethod(long value) { // ... } public Object businessMethod(long value, int i, Object value) { // ... } public Object businessMethod(long value, int i) { // ... } }
<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>businessMethod</method-name> </method> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> <concurrent-method> <method> <method-name>businessMethod</method-name> <method-params> <method-param>long</method-param> <method-param>int</method-param> </method-params> </method> <access-timeout> <timeout>8000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> </session>
이전 코드 예는 읽기의 잠금 유형과 2,000 밀리초의 액세스 제한시간을 갖는 “businessMethod”라는 모든 메소드가 됩니다. 예외는 유형 long의 첫 번째 매개변수 및 유형 int의 두 번째 매개변수를 갖는 메소드 서명을 갖는 “businessMethod” 메소드의 한 인스턴스입니다. "businessMethod" 메소드의 이 인스턴스는 읽기 잠금 유형을 갖지만 8,000 밀리초의 액세스 제한시간을 갖습니다.
스타일 1 XML이 잠금 유형만 정의하고 액세스 제한시간 값은 정의하지 않는 데 사용될 때 동일한 원리가 적용됩니다. 특정 메소드 또는 스타일 2, 스타일 3 또는 둘 다를 사용하는 메소드에 액세스 제한시간 값을 추가하여 특정 잠금 유형 및 액세스 제한시간 값 결과를 가져올 수 있습니다. 다음 예가 이 점을 설명합니다.<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>*</method-name> </method> <lock>Read</lock> </concurrent-method> <concurrent-method> <method> <method-name>businessMethod</method-name> </method> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> </session>
이전 코드 예의 결과에는 모든 비즈니스 메소드에는 읽기의 잠금 유형이 있으며, businessMethod로 이름 지정된 메소드에는 읽기의 잠금 유형 및 2,000 밀리초의 액세스 제한시간이 있습니다.
모든 메소드에 잠금 유형을 설정할 클래스 레벨 @Lock 어노테이션이 있을 수 있고 XML 작성을 위해 스타일 1을 사용하여 모든 메소드에 대한 액세스 제한시간 값만을 설정할 수도 있습니다. 다음 예를 참조하십시오.@Singleton @Lock(READ) public class ConfigurationBean implements Configuration { public Object businessMethod(long value) { // ... } // ... }
<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>*</method-name> </method> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> </session>
이전 예제의 결과로 Bean의 모든 비즈니스 메소드(ConfigurationBean)에는 읽기의 잠금 유형 및 2,000 밀리초의 액세스 제한시간 값이 있습니다.
- 사용한 어노테이션에 대한 상속 규칙을 이해해야 합니다.
- 읽기 잠금 메소드가 동일한 싱글톤 세션 Bean에서
쓰기 잠금 메소드를 호출하는 경우에 발생할 수 있는
재진입 잠금 동작을 피하십시오.
싱글톤 세션 Bean의 비즈니스 메소드가 직접 또는 간접적으로 싱글톤 세션 Bean의 다른 비즈니스 메소드가 시작되게 한다고 가정하십시오. 첫 번째 메소드가 쓰기 잠금 메소드인 경우 해당 메소드는 특별한 고려사항 없이 싱글톤 세션 Bean의 기타 비즈니스 메소드를 호출할 수 있습니다. 그러나, 쓰기 잠금 메소드인 동일한 싱글톤 세션 Bean 클래스의 또 다른 비즈니스 메소드를 호출하는 경우 읽기 잠금 메소드를 주의해서 구현할 수 있습니다. 그런 다음 javax.ejb.IllegalLoopbackException 예외가 발생합니다.
하위 주제
싱글톤 세션 Bean 잠금 정책 변경
서버 내에서 모든 싱글톤 세션 Bean 쓰기 잠금에 대한 기본적이고 공정하지 않는 잠금 정책을 대체하려면 이 태스크를 사용하십시오. 이 태스크는 싱글톤 세션 Bean 메소드 호출에 대한 잠금 요청이 공정하지 않은 정책을 따르기를 원하지 않는 WebSphere® Application Server 사용자를 위한 것입니다.싱글톤 세션 Bean 잠금 정책 변경
서버 내에서 모든 싱글톤 세션 Bean 쓰기 잠금에 대한 기본적이고 공정하지 않는 잠금 정책을 대체하려면 이 태스크를 사용하십시오. 이 태스크는 싱글톤 세션 Bean 메소드 호출에 대한 잠금 요청이 공정하지 않은 정책을 따르기를 원하지 않는 WebSphere Application Server 사용자를 위한 것입니다.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tejb_ssb
파일 이름:tejb_ssb.html