私たちは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