우리는 CommonJ work components을 사용하려는 병렬화가 필요한 Websphere Java EE 애플리케이션을 보유하고 있습니다.공통 j 구성 요소로 트랜잭션 관리
각 '스레드'는 데이터베이스에서 오는 데이터에 대한 자체보기가 필요합니다. 이것들의 대부분은 선입견이 될 것이지만 여전히 그것을 얻기 위해 데이터베이스에 갈 필요가 있습니다. 이러한 모든 스레드의 전체 작업 기간은 '긴'(즉, 기본 데이터가 변경 될 수있는 충분한 시간)이 될 것으로 예상됩니다.
결과적으로 응용 프로그램에서 사용중인 데이터를 격리하고 스레드 작업 중에 쿼리해야합니다.
이 방법을 보장하는 유일한 방법은 '글로벌'트랜잭션을 사용하고 XA 트랜잭션을 사용하는 것입니다. 그러나 우리는 가능하다면이 복잡성 (및 오버 헤드)을 피하고 아이디어 나 대안을 찾고 있습니다 : 어떤 생각입니까?
또한 Common-J Work Components는 컨테이너 관리 트랜잭션을 어느 정도까지 지원합니까?
@ 카를 : 아마 나는 오버 헤드를 의미했습니다. 우리는 XA 트랜잭션과 메시징이 트랜잭션을 공유하는 Common-J 작업 구성 요소가 피할 수있는 오버 헤드를 초래할 것이라고 생각했습니다. 작동되는 데이터 세트는> 300k 개의 별개 데이터 행이며, 각 행마다 ~ 100 개의 계산이 필요합니다. 공유 메모리, 캐시 된 읽기 전용 데이터에서 작동하는 다른 스레드로 나눌 수있는 반면, 큐에 복사하거나 큐에서 읽기위한 비교 메모리 오버 헤드는 금지되어 있습니다. 동의하니?
@ Karl : 엔티티 당 수백 밀리 초까지의 시간. 또한 로직 프로세싱을 별도의 작업으로 개선하는 데 주력하고 있습니다.
모든 스레드가 단일 데이터베이스에서 일관된 데이터보기를 가지고 있어야하는 경우 XA 트랜잭션을 사용해야합니까? 이에 대한 나의 답은 각 스레드가 자신의 JPA EntityManager (예 : 연결)를 필요로하며 액세스를 조정하기 위해 XA가 필요하다는 것입니다.
하지만 XA없이이 작업을 수행 할 수 있다면 더 좋을 것입니다. 그렇지 않습니다.
난 당신이 XA 및 메시징의 오버 헤드가 WAS에 얼마나 저에 대해 놀라게 될 것 같아, 내가 적시에 데이터를 처리 로직에 대한 자세한 걱정 것처럼 더 소리. 어떤 종류의 시간 척도 당신에게 받아 들여질 수 있으며, 얼마나 빨리 1 개체의 처리가 걸릴 것이라고 생각합니까? 아주 간단하게 WAS를 클러스터링 할 수도 있습니다. 칼 – Karl