Narayana/XAはTM障害からどのように復旧しますか？

Question

私は、同期データソースを保証するシステム/フレームワークが犯す可能性のある障害回復処置について理由を考えようとしていました。私はナラヤナの回復メカニズムについての明確な説明を見つけることができませんでした。

Q1：Narayanaは基本的に、2つのデータソース間で分散トランザクションを保証するために2フェーズコミットを採用していますか？

質問2：このシナリオでナラヤナの行動を説明できる人はいますか？

1. アプリケーションは、2つのデータストアナラ​​ヤナのトランザクション・マネージャー（TM）は、トランザクションIDを生成し、ディスクに情報を書き込み
にXを保存したいTMは現在、両方のデータ・ストアへの準備メッセージを送る
4. 各データストアはprepare_successで応答します
5. TMはローカルトランザクションログを更新し、両方のデータストアにコミットメッセージを送信します
6. TMが失敗します（永続的に）。また、ネットワーク上のパケット損失のため、1つのデータストアだけがコミットメッセージを受信します。しかし、他のデータストアは、コミットメッセージを受信して​​正常に処理します。

2つのデータストアは互いに同期していません（一方のソースには、もう一方のソースには存在しない追加のトランザクションがあります）。

新しいTMが起動されると、古いトランザクション状態レコードにアクセスすることはできません。したがって、TMはデータストアの1つで欠落しているトランザクションの回復を開始できません。

2PC/Narayana/XAは、2つのデータストアを同期して維持できる分散トランザクションをどのように保証することができますか？私の立場からは、非常に高い確率で同期データストアを維持することしかできませんが、保証はできません。

Q3：アプリケーション/フレームワークの動作が不明な別のシナリオ。

• ディ= I
• のTi =トランザクションI
• パイ=ためのメッセージを準備するデータ源： - 次のインターリーブ取引（または少なくともレコードの部分的に重複するセットと同じレコードの両方に）検討トランザクションi

D1はP1を受け取ります。 P1_successに応答します。

D2はP2を受け取ります。 P2_successに応答します。

D1はP2を受け取ります。 P2_failureに応答します。

D2はP1を受け取ります。応答P1_failure

ネットワークパケットが異なるデータソースに到達する順序によって、どの準備要求が成功するかが決まります。これは、論争の激しいレコードの高速トランザクション速度であることを意味するのではなく、すべてのトランザクションが失敗し続ける可能性があります（レコードのトランザクション要求レートが低下するまで）。

ACIDシステムとは異なり、一貫性を選択すると主張できますが、少なくとも1つのトランザクションが成功するという保証はありません（したがって、デッドロックが長続きしない可能性があります）。

Answer 1

私はナラヤナ2PCがあなたの質問に https://developer.jboss.org/wiki/TwoPhaseCommit2PC

をどのように機能するかに私の記事にあなたを参照することになり

Q1：あなたはすでにコメントでいることを述べた - はい、ナラヤナは2PC =ナラヤナを実装して使用していますXA仕様（pubs.opengroup.org/onlinepubs/009680699/toc.pdf）。

Q2：このシナリオの手順は正確ではありません。 Narayanaはprepare時にディスクに書き込むが、トランザクションが開始された時点ではない。各データストアはprepare_success

バック応答

1. アプリケーションが
2. 2つのデータ・ストアにXを節約TMは現在、両方のデータ・ストアへの準備メッセージを送る
3. TMは、恒久的に準備されたトランザクションとそのIDに関する情報が保存されますトランザクション・ログ・ストアへ
4. TMは...両方のデータ・ストア
5. にコミットメッセージを送信し

2PCが2つのデータストアを同期して維持することを保証するとは私は同意しません。 私はこれについても疑問に思っていました（ここではhttps://developer.jboss.org/message/954043と尋ねられました）。 ACIDプロパティを保証する2PCクレーム2つの店舗を同期させることは、CAPの整合性についてのものです。

このNarayanaは、特定のリソースマネージャ（データストアのデータストアまたはjdbcドライバ）の機能に厳密に依存します。 ACIDは

• アトミックを宣言 - 全体のトランザクションがコミットまたはされ、ロールバック（それが起こる無し情報、同期中にリソースに関する情報なし）
• 一貫性 - トランザクションは、システムを終了したときに一貫性のある状態になる前にと
• 耐久性 - クラッシュが発生してもすべて保存されます。
• 隔離 - （トリッキーな1つ、左端） - ACIDであるためには、シリアライズ可能でなければなりません。それはあなたが "一つずつ"起こっている取引を観察することができます。 私がかなり簡単な例をとってみると、トランザクション開始時にデータベース全体をロックする素朴な方法でポイントが予想されるDBが実装されていることを示すために、jmsメッセージをコミットして処理したので、dbレコードをコミットしません。 DBがシリアライズ可能な分離レベル（ACIDが必要とするもの）で動作する場合、次の書き込み/読み取り操作は、「飛行準備完了」トランザクションが解決されるまで待たなければなりません。 DBはちょうど立ち往生し、待っています。あなたが読むなら、あなたは答えを得ることができないので、あなたは値が何であるか言うことができません。 ナラヤナのリカバリマネージャは、接続が確立された後、準備されたトランザクションに来て、コミットします。そして、あなたは行動を読んで、「正しい」情報を返します。

質問3：申し訳ありませんが質問は分かりません。しかし、もしそれがThe order in which the network packets arrive at the different data sources can determine which prepare request succeeds.ならあなたが正しいと言えば、ネットワークがより安定するまで、失敗したトランザクションを得ることになります。