Java EE 개발에 대해 처음으로 배운 것 중 하나는 Java EE 컨테이너 내부에 자체 스레드를 생성해서는 안된다는 것입니다. 근데 생각 해보니 그 이유를 모르겠어요.
낙담 한 이유를 명확하게 설명 할 수 있습니까?
대부분의 엔터프라이즈 응용 프로그램에는 메일 데몬, 유휴 세션, 정리 작업 등과 같은 일종의 비동기 작업이 필요합니다.
그렇다면 실제로 스레드를 생성하지 않아야한다면 필요할 때 올바른 방법은 무엇입니까?
답변
환경 내의 모든 리소스는 서버에 의해 관리되고 잠재적으로 모니터링되기 때문에 권장되지 않습니다. 또한 스레드가 사용되는 대부분의 컨텍스트는 일반적으로 실행 스레드 자체에 연결됩니다. 단순히 자신의 스레드를 시작하면 (일부 서버는 허용하지 않을 것이라고 생각합니다) 다른 리소스에 액세스 할 수 없습니다. 이것이 의미하는 바는 InitialContext를 가져올 수없고 JMS 연결 팩토리 및 데이터 소스와 같은 다른 시스템 자원에 액세스하기 위해 JNDI 검색을 수행 할 수 없다는 것입니다.
이 작업을 “올바르게”수행하는 방법이 있지만 사용중인 플랫폼에 따라 다릅니다.
commonj WorkManager는 WebSphere 및 WebLogic 및 기타 공통 사항입니다.
또한 다소 중복 이 일 이 아침부터를
업데이트 :이 질문과 답변은 2009 년의 Java EE 상태와 관련이 있으며 그 이후로 상황이 개선되었습니다!
답변
EJB의 경우 권장 사항 일뿐만 아니라 사양에 의해 명시 적으로 금지되어 있습니다 .
엔터프라이즈 Bean은 여러 인스턴스의 실행을 동기화하기 위해 스레드 동기화 기본 요소를 사용하지 않아야합니다.
과
엔터프라이즈 Bean은 스레드 관리를 시도하지 않아야합니다. 엔터프라이즈 Bean은 스레드를 시작, 중지, 일시 중단 또는 재개하거나 스레드의 우선 순위 또는 이름을 변경하지 않아야합니다. 엔터프라이즈 Bean은 스레드 그룹을 관리하려고 시도하지 않아야합니다.
그 이유는 EJB가 분산 환경에서 작동하기위한 것입니다. EJB는 클러스터의 한 시스템에서 다른 시스템으로 이동할 수 있습니다. 스레드 (및 소켓 및 기타 제한된 기능)는이 이식성에 대한 중요한 장벽입니다.
답변
자신의 스레드를 생성하지 않아야하는 이유는 컨테이너가 스레드를 관리하지 않기 때문입니다. 컨테이너는 초보 개발자가 상상하기 어려운 많은 것들을 처리합니다. 예를 들어 스레드 풀링, 클러스터링, 크래시 복구와 같은 작업은 컨테이너에서 수행됩니다. 스레드를 시작하면 일부가 손실 될 수 있습니다. 또한 컨테이너를 사용하면 실행되는 JVM에 영향을주지 않고 애플리케이션을 다시 시작할 수 있습니다. 컨테이너가 제어 할 수없는 스레드가 있다면 어떻게 가능할까요?
이것이 J2EE 1.4에서 타이머 서비스가 도입 된 이유입니다. 자세한 내용은 이 기사를 참조하십시오.
답변
Java EE 용 동시성 유틸리티
이제 핵심 Java EE API를 사용하여 스레드를 만드는 표준적이고 올바른 방법이 있습니다.
Concurrency Utils를 사용하면 컨테이너에서 새 스레드를 만들고 관리하여 모든 EE 서비스를 사용할 수 있습니다.
여기에 예
답변
배포 설명 자의 일부로 항목을 시작하도록 컨테이너에 항상 지시 할 수 있습니다. 그런 다음 필요한 유지 관리 작업을 수행 할 수 있습니다.
규칙을 따라. 언젠가 당신은 기뻐할 것입니다 🙂
답변
청사진에 따라 Java EE 컨테이너에서 스레드가 금지됩니다. 자세한 내용은 청사진 을 참조하십시오.
답변
그렇게하지 않을 실제 이유가 없습니다. 나는 문제없이 webapp에서 Spring 과 Quarz 를 사용했습니다 . 또한 동시성 프레임 워크를 사용할 수 있습니다. 자체 스레드 처리를 구현하는 경우 컨테이너가 언제든지 웹앱을 언로드 할 수 있도록 theads를 deamon으로 설정 하거나 자체 deamon 스레드 그룹을 사용합니다.java.util.concurrent
그러나 빈 범위 세션 및 요청 은 생성 된 스레드에서 작동하지 않습니다. 또한 다른 코드는 기본적으로 ThreadLocal작동하지 않으므로 생성 된 스레드로 값을 직접 전송해야합니다.
