「AP過去問令和6年度秋期午前問27」の版間の差分

2024年11月28日 (木) 00:00時点における最新版

問27(問題文)

　2相コミットで分散トランザクションの原子性を保証する場合、ネットワーク障害の発生によって参加者のトランザクションがコミットすべきか又はロールバックするべきかを判断できなくなることがある。このような状況を発生させるネットワーク障害に関する説明として、適切なものはどれか。

ア　調停者のトランザクションが、コミット又はロールバック可否の問合せを参加者に送る直前に障害になった。

イ　調停者のトランザクションが、コミット又はロールバックの決定を参加者に送る直前に障害になった。

ウ　調停者のトランザクションに、コミット又はロールバック可否の応答を参加者が返す直前に障害になった。

エ　調停者のトランザクションに、コミット又はロールバックの完了を参加者が返す直前に障害になった。

回答・解説

2相コミットプロトコルの概要

2相コミット(2PC:Two-Phase Commit)は、分散トランザクションでの原子性(全参加者が一貫した状態で完了すること)を保証するためのプロトコルです。ここでいう参加者や調停者は人ではなく、分散システム内のソフトウェアコンポーネントやシステムの役割を指します。以下の2つのフェーズがあります：

準備フェーズ(Prepare Phase)

調停者(コーディネータ)が各参加者にコミットの可否を確認します。
参加者は「YES(コミット可能)」または「NO(コミット不可)」で応答します。

コミットフェーズ(Commit Phase)

調停者が全員から「YES」の応答を受け取った場合、各参加者にコミット指示を送ります。
1人でも「NO」があれば、全員にロールバック指示を送ります。

問題となる状況

調停者が「コミット」または「ロールバック」を決定していながら、その結果を全参加者に通知する前に障害が発生すると、参加者は次の指示を待機したままとなり、状態が不明(ブロック状態)になる可能性があります。調停者の下した決定が保存されていないし、問題が起きたことを認識できていないので、リトライや再送信で解決する問題ではありません。

　アの調停者がコミット又はロールバック可否の問合せを参加者に送る直前に障害になったは誤りです。

　この時点では、コミットまたはロールバックの決定が行われていないため、トランザクションの状態はまだ明確です。再送信やリトライ処理で解決可能です。

　イの調停者がコミット又はロールバックの決定を参加者に送る直前に障害になったは正解です。

　この状況では、調停者が「コミット」または「ロールバック」を決定した後に、その結果を参加者に通知できないため、参加者側では次に何をすべきか分からなくなります。このような状態をブロック状態と呼び、2PCの主要な課題の一つです。

　ウの調停者にコミット又はロールバック可否の応答を参加者が返す直前に障害になったは誤りです。

　参加者が応答する前であれば、調停者は参加者からの応答を待つだけで、プロトコル全体が進行しないことが明確です。障害発生時にリトライ処理で対応可能です。

　エの調停者にコミット又はロールバックの完了を参加者が返す直前に障害になったは誤りです。

　この場合、参加者はすでにコミットまたはロールバックの指示を受けています。調停者が障害から復旧すれば、トランザクションの整合性を保つことが可能です。

　したがって

イ

　が答えです。ブロック状態になるイのタイミングの障害は覚えておいた方がいいようです。

AP過去問令和6年度秋期午前問26へ

AP過去問令和6年度秋期午前問28へ

AP過去問令和6年度秋期午前問題に戻る

@@ 6行目: / 6行目: @@
 =='''問27(問題文)'''==
+相コミットで分散トランザクションの原子性を保証する場合、ネットワーク障害の発生によって参加者のトランザクションがコミットすべきか又はロールバックするべきかを判断できなくなることがある。このような状況を発生させるネットワーク障害に関する説明として、適切なものはどれか。
+ア　調停者のトランザクションが、コミット又はロールバック可否の問合せを参加者に送る直前に障害になった。
+イ　調停者のトランザクションが、コミット又はロールバックの決定を参加者に送る直前に障害になった。
+ウ　調停者のトランザクションに、コミット又はロールバック可否の応答を参加者が返す直前に障害になった。
+エ　調停者のトランザクションに、コミット又はロールバックの完了を参加者が返す直前に障害になった。
 =='''回答・解説'''==
+'''2相コミットプロトコルの概要'''
+相コミット(2PC:Two-Phase Commit)は、分散トランザクションでの原子性(全参加者が一貫した状態で完了すること)を保証するためのプロトコルです。ここでいう参加者や調停者は人ではなく、分散システム内のソフトウェアコンポーネントやシステムの役割を指します。以下の2つのフェーズがあります：
+'''準備フェーズ(Prepare Phase)'''
+*調停者(コーディネータ)が各参加者にコミットの可否を確認します。
+*参加者は「YES(コミット可能)」または「NO(コミット不可)」で応答します。
+'''コミットフェーズ(Commit Phase)'''
+*調停者が全員から「YES」の応答を受け取った場合、各参加者にコミット指示を送ります。
+*1人でも「NO」があれば、全員にロールバック指示を送ります。
+'''問題となる状況'''
+調停者が「コミット」または「ロールバック」を決定していながら、その結果を全参加者に通知する前に障害が発生すると、参加者は次の指示を待機したままとなり、状態が不明(ブロック状態)になる可能性があります。調停者の下した決定が保存されていないし、問題が起きたことを認識できていないので、リトライや再送信で解決する問題ではありません。
+　アの調停者がコミット又はロールバック可否の問合せを参加者に送る直前に障害になったは誤りです。
+　この時点では、コミットまたはロールバックの決定が行われていないため、トランザクションの状態はまだ明確です。再送信やリトライ処理で解決可能です。
+　イの調停者がコミット又はロールバックの決定を参加者に送る直前に障害になったは正解です。
+　この状況では、調停者が「コミット」または「ロールバック」を決定した後に、その結果を参加者に通知できないため、参加者側では次に何をすべきか分からなくなります。このような状態をブロック状態と呼び、2PCの主要な課題の一つです。
+　ウの調停者にコミット又はロールバック可否の応答を参加者が返す直前に障害になったは誤りです。
+　参加者が応答する前であれば、調停者は参加者からの応答を待つだけで、プロトコル全体が進行しないことが明確です。障害発生時にリトライ処理で対応可能です。
+　エの調停者にコミット又はロールバックの完了を参加者が返す直前に障害になったは誤りです。
+　この場合、参加者はすでにコミットまたはロールバックの指示を受けています。調停者が障害から復旧すれば、トランザクションの整合性を保つことが可能です。
+　したがって
+<span style = "background:linear-gradient(transparent 75%, #7fbfff 75%); font-weight:bold; ">
+イ</span>
+　が答えです。ブロック状態になるイのタイミングの障害は覚えておいた方がいいようです。