ネストされたトランザクションがJTAでサポートされていないのはなぜですか?それは、それらを実装することの複雑さ(私は疑わしい)またはいくつかの設計原則のためですか?
3 に答える
JTA仕様は、ネストされたトランザクションをサポートしないとは言っていません。実装者がサポートする必要がないだけです。
以下の抜粋は、JTA1.1仕様から抜粋したものです。
p。11、13; 3.1UserTransactionインターフェースおよび3.2TransactionManagerインターフェース
「ネストされたトランザクションのサポートは必要ありません。」
p。13、3.2.1トランザクションの開始
「トランザクションマネージャーの実装がネストされたトランザクションをサポートしていない場合、呼び出し元のスレッドがすでにトランザクションに関連付けられていると、TransactionManager.beginメソッドはNotSupportedExceptionをスローします。」
実際にはXAResource
、現在のトランザクションに参加しようとする可能性があるという問題がある可能性があります(X / Open XA仕様に関連している可能性があると思います)。
3.4.4トランザクションアソシエーション
XAResourceは、ネストされたトランザクションをサポートしていません。XAResource.startメソッドが、現在別のトランザクションに関連付けられている接続で呼び出されるのはエラーです。
(@Piotr Nowickiが指摘しているように、JTAはネストされたトランザクションを許可しますが、これはオプションであり、必須ではありません。)
なんで?これは、決定が下されたときに「部屋にいる」人の1人でない限り、確実に答えることができない質問の1つです。
これは、仕様の一部としてネストされたトランザクションを含めることの本質的な複雑さである可能性があります。または、当時の明らかな複雑さ。つまり、彼らは彼らを特定するための良い仕事をする方法を知っていると確信していませんでした。
需要が足りないと思っていたのかもしれません。
それは時間のプレッシャーかもしれません...または単なる疲労感です。
それは「商業的理由」である可能性があります。たとえば、仕様の範囲を拡大することによって製品の発売スケジュールに干渉したくない特定のベンダー。
しかし、肝心なのは、本当の答えが必要な場合は、JTA仕様を作成したワーキンググループの人々に尋ねる必要があるということです。(そして私は彼らがあなたに言うだろうとは思わない...記録上。)
そのどちらの答えもビジネスではありません。
JBossなどの多くのコンテナーは、ネストされたトランザクションなどの概念をサポートするより複雑な代替トランザクションマネージャーを提供しますが、Glassfishなどの他のコンテナーはサポートしません。ただし、これらは両方ともJavaEEに準拠しています。仕様をシンプルに保ち、ベンダーのコンプライアンスの障壁を下げるという考え方です。
トランザクションのユースケースの0.5%しかカバーしない複雑なトランザクションマネージャーを誰かに実装させたり、Java EEへの準拠を放棄させたりするのはなぜですか?
野心的なベンダーが仕様を超えていくのを止めるものは何もありませんが、何も除外するオプションはありません。