[SPRING] 비 관리 스레드 Spring Quartz Websphere Hibernate

비 관리 스레드 Spring Quartz Websphere Hibernate

Spring, Hibernate 및 Websphere와 함께 Quartz - JDBCJobStore를 사용하여 구현 한 것이 관리되지 않는 스레드를 던지고있는 것처럼 보입니다.

필자는 독서를 한 적이 있으며 IBM에서 Quartz와 Spring의 사용으로 인해 발생하는 기술 관련 기사를 발견했습니다. 그들은 CommnonJ를 사용하여이 문제를 해결할 것을 제안합니다.

나는 더 깊은 연구를 해왔고 지금까지 데이터베이스에서 찾을 수없는 계획 JobStore를 다루는 유일한 예를 보았습니다.

그래서 누군가가이 문제에 대한 해결책의 예가 있는지 궁금합니다.

감사

해결법

1. ==============================

   1.우리는 이것을위한 실제 해결책을 가지고있다.

   우리는 이것을위한 실제 해결책을 가지고있다.

   1) 기본 스케줄러 스레드에 WorkManager 디먼 스레드를 사용하도록 석영 소스 코드를 변경하십시오. 그것은 효과가 있지만 변화하는 쿼트가 필요합니다. 해킹 된 석영 버전을 유지하고 싶지 않았기 때문에 우리는 이것을 사용하지 않았습니다. (그것은 나를 생각 나게한다, 나는 프로젝트에 이것을 제출할 예정였다. 그러나 완전하게 잊었다)

   2) 석영 스레드 풀로 사용할 WorkManagerThreadPool을 만듭니다. Quartz ThreadPool에 대한 인터페이스를 구현하여 쿼츠 내에서 트리거되는 각 태스크가 WorkManager에서 스케쥴링되는 commonj Work 오브젝트로 랩핑되도록한다. 핵심은 WorkManagerThreadPool의 WorkManager가 Java EE 스레드 (예 : 서블릿 초기화)에서 스케줄러가 시작되기 전에 초기화되어야한다는 것입니다. 그런 다음 WorkManagerThreadPool은 새 Work 객체를 만들고 예약하여 모든 예약 된 작업을 처리하는 데몬 스레드를 만들어야합니다. 이렇게하면 스케줄러 (자체 스레드)가 관리되는 스레드 (작업 디먼)로 태스크를 전달합니다.

   간단하지 않고 유감스럽게도 포함 할 수있는 코드가 없습니다.

2. ==============================

   2.마지막으로 스레드에 다른 대답을 추가했습니다.

   마지막으로 스레드에 다른 대답을 추가했습니다.

   내 환경 : WAS 8.5.5, Quartz 1.8.5, 스프링 없음.

   내가 가진 문제는 위의 (명시된) 관리되지 않는 스레드가 ctx.lookup (myJndiUrl)의 NamingException을 유발하여 다른 응용 프로그램 서버 (JBoss, Weblogic)에서 정상적으로 작동하고있었습니다. 사실, Webpshere는 다음과 같은 메시지로 "사건"을 일으켰습니다.

   다음 단계에 따라 문제가 해결되었습니다.

   1) 석영 1.8.6 (코드 변경 없음)으로 업그레이드, 단지 maven pom

   2) 클래스 패스 (내 경우에는 EAR의 / lib 폴더)에 다음과 같은 dep를 추가하여 새로운 WorkManagerThreadExecutor를 사용 가능하게 만든다.

   <dependency>
     <groupId>org.quartz-scheduler</groupId>
     <artifactId>quartz-commonj</artifactId>
     <version>1.8.6</version>
   </dependency>
   

   참고 : QTZ-113 또는 공식 Quartz Documentation 1.x 2.x에는이 수정을 활성화하는 방법에 대한 언급이 없습니다.

   3) quartz.properties에 다음을 추가했다 ( "wm / default"는 WAS 8.5.5의 이미 구성된 DefaultWorkManager의 JNDI이다. 참고 자료 -> AsynchronousBeans -> WAS 콘솔의 WorkManager).

   org.quartz.threadExecutor.class=org.quartz.custom.WorkManagerThreadExecutor
   org.quartz.threadExecutor.workManagerName=wm/default
   

   참고 : 오른쪽 클래스는 quartz-scheduler-1.8.6 (테스트 됨)의 경우 org.quartz.custom.WorkManagerThreadExecutor이고 2.1.1의 경우 org.quartz.commonj.WorkManagerThreadExecutor는 테스트되지 않지만 실제 quartz-commonj의 jar 파일 내에서 확인됩니다. 메이븐 리포 지)

   4) 쿼츠 작업의 빈 생성자에서 JNDI 조회를 이동했습니다 (m_klovre의 "J2EE 컨테이너 외부의 스레드"덕분에). 즉, 생성자가 내 응용 프로그램과 매우 유사한 J2EE 컨텍스트에서 리플렉션 (newInstance () 메서드)에 의해 호출되고 java : 전역 네임 스페이스에 액세스 할 수 있지만 execute (JobExecutionContext) 메서드는 여전히 빈곤 한 컨텍스트에서 실행 중이지만, 내 응용 프로그램의 모든 EJB가 누락되었습니다.

   희망이 도움이됩니다.

   추신. 참고로 위에 사용했던 quartz.properties 파일의 예를 찾을 수 있습니다.

3. ==============================

   3.이 기사 확인 : http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html

   이 기사 확인 : http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html

   기본적으로 컨테이너 관리 스레드를 사용할 org.springframework.scheduling.commonj.WorkManager TaskExecutor를 사용하도록 SchedulerFactoryBean에서 taskExecutor 속성을 설정하십시오.

4. ==============================

   4.참고 : 위의 QUARTZ-708 링크는 더 이상 유효하지 않습니다. 이 새로운 문제 (새로운 Jira에서)는 문제를 해결하는 것으로 보인다 : http://jira.terracotta.org/jira/browse/QTZ-113 (fixVersion = 1.8.6, 2.0.2)

   참고 : 위의 QUARTZ-708 링크는 더 이상 유효하지 않습니다. 이 새로운 문제 (새로운 Jira에서)는 문제를 해결하는 것으로 보인다 : http://jira.terracotta.org/jira/browse/QTZ-113 (fixVersion = 1.8.6, 2.0.2)

5. ==============================

   5.이것에 관해서는 아래의 JIRA 링크를 확인하십시오.

   이것에 관해서는 아래의 JIRA 링크를 확인하십시오.

   http://jira.opensymphony.com/browse/QUARTZ-708

   여기에는 요구 사항을 충족시키기 위해 언급 한 quartz.properties의 변경 사항과 함께 사용할 수있는 필수 WebSphereThreadPool 구현이 있습니다. 희망이 도움이됩니다.

   문안 인사, 시바

6. ==============================

   6.websphere의 관리되는 스레드 풀을 사용해야합니다. 당신은 spring과 commonj를 통해 이것을 할 수 있습니다. CommonJ는 관리 스레드를 작성할 태스크 실행 프로그램을 가질 수 있습니다. JNDI 관리 스레드 자원에 대한 참조를 사용할 수도 있습니다. 그런 다음 commonj 태스크 실행기를 스프링 기반 Quartz SchedulerFactoryBean에 삽입 할 수있다.

   websphere의 관리되는 스레드 풀을 사용해야합니다. 당신은 spring과 commonj를 통해 이것을 할 수 있습니다. CommonJ는 관리 스레드를 작성할 태스크 실행 프로그램을 가질 수 있습니다. JNDI 관리 스레드 자원에 대한 참조를 사용할 수도 있습니다. 그런 다음 commonj 태스크 실행기를 스프링 기반 Quartz SchedulerFactoryBean에 삽입 할 수있다.

   자세한 내용은 http://open.bekk.no/boss/spring-scheduling-in-websphere/를 참조하고 "CommonJ을 사용하는 Quartz"섹션으로 스크롤하십시오.

7. ==============================

   7.WAS85 및 Quartz 1.8.6 용 PaoloC의 제안은 WAS80 (및 Quartz 1.8.6)에서도 작동하며 Spring을 필요로하지 않습니다. (내 설정에서 Spring 2.5.5는 존재하지만 그 상황에서는 사용되지 않는다.)

   WAS85 및 Quartz 1.8.6 용 PaoloC의 제안은 WAS80 (및 Quartz 1.8.6)에서도 작동하며 Spring을 필요로하지 않습니다. (내 설정에서 Spring 2.5.5는 존재하지만 그 상황에서는 사용되지 않는다.)

   그런 식으로 내 자신의 변형으로 SimpleJobFactory를 재정의 할 수있었습니다. InjectionHelper를 사용하여 새로 생성 된 모든 작업에 CDI를 적용 할 수있었습니다. 주입은 @EJB (주석 된 EJB 원격 비즈니스 인터페이스의 JNDI 조회 사용) 및 @Inject (새 InitialContext를 사용하여 CDI BeanManager의 JNDI 조회를 먼저 수행 한 다음이 새로 가져온 BM을 사용하여 CDI Bean 자체를 조회합니다).

   그 대답에 대해 PaoloC에게 감사드립니다! (이 텍스트가 "PaoloC에 대한 답변"으로 표시되고 주요 주제에 대한 답변으로 표시되지 않기를 바랍니다. 이들을 구별 할 방법이 없습니다.)

8. ==============================

   8.최근에이 문제가 발생했습니다. 실질적으로 다음이 필요합니다.

   최근에이 문제가 발생했습니다. 실질적으로 다음이 필요합니다.

   다음은 Websphere (및 Tomcat)와 함께 Quartz를 사용하는 github 데모입니다.

   희망은 누군가를 돕는 ..

from https://stackoverflow.com/questions/175880/unmanaged-threads-spring-quartz-websphere-hibernate by cc-by-sa and MIT license