Stateless EJB local (instance) 변수

Question

내가 달성하고자하는 것은 EJB 기능을 활용하고 일종의 자동 풀링을 사용하는 것이다.

로컬 상태 비 저장 변수 (적절한 정의인지 모르는 경우)을 유지할 때 SLSB가 적합 할 수 있다고 생각했습니다. 적어도 클라이언트/호출자 POV에서. 내가 프로세스의 풀을 원하는

@Stateless 
public class CommunicationService implements Serializable 
{ 
    private Process process; 

    @PostConstruct 
    //@PostActivate maybe? 
    public void startProcess() 
    { 
     try 
     { 
      process = new ProcessBuilder("running a temporary daemon").start(); 
     } 
     catch(IOException e) 
     { 
      throw new RuntimeException(e.getMessage(), e); 
     } 
    } 


    @PreDestroy 
    //@PrePassivate maybe? 
    public void endProcess() 
    { 
     if(process.isAlive()) 
     { 
      process.destroy(); 

      boolean terminated = false; 
      try 
      { 
       terminated = process.waitFor(5, TimeUnit.SECONDS); 
      } 
      catch(InterruptedException e) 
      { 
       // ignore 
      } 

      if(!terminated) 
      { 
       process.destroyForcibly(); 
      } 
     } 
    } 

    public int send(String message) 
    { 
     // do something with the process - may take a long time 
     // this is just an example 

     PrintStream printStream = new PrintStream(process.getOutputStream()); 
     printStream.println(message); 

     try 
     { 
      return process.getInputStream().read(); 
     } 
     catch(IOException e) 
     { 
      return -1; 
     } 
    } 
} 

주, 그래서 @Singleton들 적합하지 않습니다.

1. @Stateless EJB 인스턴스 변수를 올바르게 사용하고 있습니까?
2. @MessageDriven이 더 적절합니까?
3. 더 있나요? EE 방법이 있습니까?

감사

Answer 1

, 그것은 SLSBs의 상태를 유지하는 것은 매우 괜찮아요 정보 나이 읽기. 단지 고객 상태 일 수 없습니다. EJB 3.2 스펙의 §4.7은 다음과 같이 말합니다 :

"stateless"라는 용어는 인스턴스에 특정 클라이언트에 대한 상태가 없음을 나타냅니다. 그러나 인스턴스의 인스턴스 변수에는 클라이언트가 호출 한 메소드 호출에 걸쳐 상태가 포함될 수 있습니다. 이러한 상태의 예로는 데이터베이스 연결 열기 및 엔터프라이즈 bean 오브젝트에 대한 오브젝트 참조가 있습니다.

• 사양은 "무 상태 세션 빈 인스턴스가 는 일반적으로 풀링이다"라고 말한다 :

따라서,이 몇 가지주의와 가능한 전략이 될 수 있습니다. 당신은 선택된 JavaEE 서버 구현이 실제로 그것들을 풀 (pooling)하는지 점검 할 필요가있다. 왜냐하면 (적어도 잠시 동안) 그 중 일부는 매번 새로운 인스턴스를 생성하기 때문이다.

풀의 빈 수를 제어하는 ​​것은 까다로운 작업 일 수 있습니다. 풀이 꽉 찬 경우에도 구현은 계속 빈 인스턴스를 생성 할 수 있으며 풀에 반환하지는 않습니다.

비즈니스 메소드에서 임의의 유형의 RuntimeException이 발생하면 @PreDestroy 콜백 (EJB 3.2 스펙 9.3.1 참조)을 호출하지 않고도 Bean 인스턴스가 삭제됩니다. 이로 인해 시스템에서 프로세스 누수가 발생합니다.

따라서 서버가 SLSB 풀을 관리하는 방식에 친숙해야합니다.

Answer 2

은 저를 위해, 당신은 팩토리 메소드 패턴를 구현해야;

대중적인 신념에 반대 EJB Factory Class