Adam Bien의 JavaEE 야간 해킹 책에서 EJB 컨테이너에서 스레드 생성이 금지되어 있지만 웹 컨테이너에는 해당하지 않는다고 읽었습니다. 실제로 Tomcat에서 실행되는 X-Ray 프로브에 스레드 풀 실행 프로그램을 만듭니다.JavaEE EJB/웹 컨테이너에서 스레드 생성
저는 조금 혼란스러워합니다. EE 애플리케이션에서 수동 스레드 풀 관리를해야하는 상황에 직면 해있는 동안 JavaEE 컨테이너에 스레드를 수동으로 생성하는 것이 왜 나쁜지 이해할 수 있습니다. 그러나 EJB 컨테이너 중 큰 부분을 배포 할 수있는 경우 EJB 컨테이너와 스레드 생성을 고려한 웹 컨테이너의 차이점을 이해하지 못합니다. 웹 컨테이너에서 세션 빈을 생성하는 세션 빈에 문제가 없다면 동일한 세션 빈을 EJB 컨테이너에 배포하면 어떤 문제가 발생할 수 있습니까?
여기가 Java EE의 "엔터프라이즈"부분이 실제 세계를 충족시키는 곳입니다.
"엔터프라이즈"시스템 사용의 전제는 대부분 관리를 중심으로 이루어집니다. 이러한 리소스를 관리하기 위해 응용 프로그램 자체에 의존하는 것이 아니라 컨테이너에 대한 의사 결정 및 구성을 특히 중요하게 생각합니다. 시스템 관리자는 애플리케이션 코드에서 리소스 생성 및 관리를 분리하고 컨테이너에 의존함으로써 해당 리소스에 대한 가시성과 액세스 권한을 확보함으로써 더 높은 수준에서 일반적인 방법으로 애플리케이션을 조정 및 모니터링 할 수 있습니다. 이를 위해 응용 프로그램 특정 메커니즘을 사용하는 것보다.
이것이 바로 우리가 속한 환경이며 Java EE 사양의 이러한 "규칙"을 통해 사용자가 수행 할 수있는 작업과 수행 할 수없는 작업에 대한 내용입니다.
이제 서블릿 컨테이너 사양이 와일드 웨스트입니다. 이러한 모든 "엔터프라이즈"관리 기능 (마음, 많은 컨테이너가이 기능을 제공하지만 스펙에는 언급되지 않음)이 없습니다. 예를 들어 정적 파일을 제공하는 것은 웹 컨테이너의 빵 및 버터 기능이므로 개발자가 언급 한 파일에 대한 액세스를 제한하는 것은 거의 불가능합니다. 게다가, 서블릿 스펙은 EJB 스펙보다 먼저 나오며 환경에 비추어 다시 작성하지 않고 환경에 볼트로 고정되었습니다.
이렇게하면 스레드와 같은 특정 항목에 대한 두 가지 "모순 된"사양이 제공됩니다.
그래서 Servlet 사양은 Java EE 응용 프로그램에서도 자신의 스레드 풀을 관리 할 수 있습니다. 물론 이러한 스레드 풀이 동일한 JVM에있을 가능성이 높습니다 (따라서 "관리하기 어려운"Java EE 자원)을 Java EE 컨테이너로 사용합니다.
현실 세계에서 의미가 끝나는 것은 원할 경우 Java EE 컨테이너 또는 서블릿 컨테이너에서 스레드 등을 스풀링 할 수 있다는 것입니다. 인기있는 컨테이너로는이 작업을 수행 할 수 없습니다 (WebSphere는 사용할 수 없습니다).
하지만 그렇게해서는 안됩니다. Java EE (특히 Java EE 6)에는 스레드 풀을 사용하는 대신 작업을 수행 할 수있는 메커니즘과 기능이 있습니다.WorkManagers, JMS 대기열, 비동기 세션 Bean, 타이머 작업 등.
서블릿 앱에서 이러한 메커니즘의 대부분은 존재하지 않으므로이를 활용할 수 없으므로 대신 "Java 만 사용"하십시오.
Java EE 앱과 함께 배포 된 웹 응용 프로그램에서 "Just Java"를 사용하는 것이 컨테이너 내에서의 가시성입니다. 예를 들어, 웹 애플리케이션은 스레드 풀의 크기를 설정하기 위해 자체 구성 변수를 필요로하며이를 관리하기 위해 컨테이너에 의존 할 수 없습니다.
결국 일반적으로 No Big Deal입니다. Java EE의 대부분의 복잡성은 많은 사람들이 사용하지 않는 관리 기능을 중심으로 이루어집니다. 나 자신을 위해, 나는 Java EE를 사용하고 평범한 WAR를 사용하는 경우는 드물다. 가능한 한 많은 것을 컨테이너에 밀어 넣고 싶다. 즉, 자바 EE 컨테이너에서 WAR로 실행되는 커스텀 소켓 서버가 있으며, 훨씬 쉬운 작업이기 때문에 상상할 수없는 모든 규칙을 깨뜨린 것입니다. "Java EE Way"는 우리가 원하는 것을 충분히 유연하게 처리 할 수있는 곳이 아니 었습니다. 그래서 우리는 "Just Java"로 가서 코드를 WAR에 쏟았습니다. 그래서 우리는 Wild Wild West에서 게임을 할 수있었습니다. 자신의 스레드를 관리합니다.
EJB는 서버에서 관리됩니다. 관리 수단, 즉 의존성 주입. 주석을 사용하여 클래스에서 스레드를 생성하면 서버가 처리 할 수 없습니다 (@PostConstruct, 참조 삽입 등).
유일한 문제입니까? 컨테이너 관리 기능을 필요로하지 않고 멀티 스레드 컴퓨팅 또는 네트워크 작업을 수행하려는 경우 수동으로 스레드 풀을 만드는 것이 좋습니다. –
스레드 풀은 서버/컨테이너에 의해 관리되며 이런 방식으로 유지되어야합니다. stateful/stateless beans로 계산을 수행 할 수 없습니까? 그것이 Enterprise Java Beans의 철학이기 때문에 스레드는 잊어 버리고 콩을 사용하십시오. 하지만 EJB 컨테이너에 스레드를 생성 할 수 없다 ... –
또한, 내가 아는 한 (정확한 참조를 찾을 수 없다) EJB 컨테이너는 가능한 한 많은 메모리를 사용하여 (그리고 관리한다.) 따라서 스레드를 생성한다. 즉, 컨테이너가 관리하는 다른 객체와 마찬가지로 메모리 요구 사항 인 컨테이너가 컨테이너를 해제하지 않기 때문에 "메모리 부족"예외가 발생할 수 있습니다. –
EJB는 항상 EJB 컨테이너에서 실행되므로 EJB에 수동으로 스레드를 생성해서는 안됩니다. 패키지가 WAR 파일 (웹 모듈)로 패키지 된 경우에도 EJB 컨테이너에서 실행되며 스레드 생성과 관련하여 동일한 제한 사항을 갖습니다.
그러나 서블릿과 필터는 웹 컨테이너에서 실행되기 때문에 직접 관리되는 스레드 풀이 없어도 아무 것도 할 수 없습니다.
포괄적 인 답변을 주셔서 감사합니다. Java EE에 대한 전문 지식이별로 없지만 플랫폼에 대한 포괄성에도 불구하고 용이성이 항상 이러한 규칙을 위반하는 이유라고 생각하지 않습니다. –