jbpm Runtime strategy

총 3가지가 있는데 디폴트는 Singleton이다
성능테스트시에 was 쪽에 병목 현상이 일어나서 확인해본결과 아래의 내용대로 실행전략을 잘짜야겠다는 생각을 했다.
성능테스트를 위해 Per request로 모두 수정하여 테스트를 진행하였다.

Singleton stratege

KieSession 및 TaskService의 단일 인스턴스를 유지 합니다. 동기화로 인해서 성능이 저하되어 있긴 하지만 Thread safe하고 엑세스를 동기화 합니다. 아래와 같은 특징을 제공합니다.

• RuntimeEngine 및 taskService의 단일 인스턴스.
• 간단한 디자인과 컴팩트.
• 동기화 액세스 하는 프로세스 엔진중 괜챃음
• 하나의 KieSession instance의 모든 상태 object를 알수 있다.
• RuntimeManager간에 사용되는 KieSession의 ID 추적은 같은 세션을 사용합니다. 아래 설정의 임시위치에 이 ID가 저장이 됩니다.
  • jbpm.data.dir
  • jboss.server.data.dir
  • java.io.tmpdir

Per request strategy

모든 요청에 대해 RuntimeEngine의 새로운 객체를 제공합니다. 요청이 완료되면 RuntimeEngine이 영구적으로 제거 됩니다.

• KieSession 정보가 DB에서 제거됨.
  아래와 같은 특징을 제공합니다

• 모든 요청에 대해 완전히 격리된 프로세스 엔진 및 태스트 서비스를 운영함.

• 높은 부하에 대한 적합

• KieSession 요청의 수명 시간 동안 만 사용할 수 있음.

Per process instance strategy

KieSession과 ProecssInstance사이의 엄격환 관계를 유지합니다. 이 전력은 최대의 성능 및 가장 유연한 접근 방식을 제공.
아래와 같은 특징을 제공합니다.

• ProcessInstance에 대해 동일한 KieSession을 제공하는것을 보장한다
• ProcessInstance는 모든 프로세스 인스턴스 완료/중단 시 KieSession의 라이프 사이클을 병합
• 프로세스 인스턴스는 해당 데이터에 액세스 할 수 있습니다.
• Context instance 허용
  • EmptyContext 나 null : 사용가능한 프로세스 인스턴스 ID가 없다
  • ProcessInstanceIDContext : 프로세스 인스턴스가 생성된 후 사용
  • CorrelationKeyContext - 프로세스 InstanceID의 키를 대신해서 사용