応用情報技術者 2014年 秋期 午後 問06
分散トランザクションに関する次の記述を読んで、設問1~4に答えよ。
L社は事務用品を扱う商社であり、顧客からの注文に基づき、商品を発送している。販売管理システム、在庫管理システムの二つのシステムを使って受注処理、在庫管理、発送処理を行っている。二つのシステム間で受注データと在庫データの整合性をとるために、昼間に登録した受注データを基に夜間バッチ処理で在庫データの管理を行っている。しかし、在庫の引当てがリアルタイムでないので、在庫量の適正化ができないという問題がある。そこで、リアルタイムに在庫管理を行うことができる統合販売管理システム(以下、本システムという)を構築することになった。
〔本システムの概要〕
本システムは、現在の販売管理システムと在庫管理システムで、それぞれ異なるDBMSを使って運用している受注データベースと在庫データベースをそのまま活用し、受注処理、在庫引当てをリアルタイムで行う受注処理及び在庫管理の機能を提供する。本システムのシステム構成を図1に示す。

〔受注処理の概要〕
・営業担当者は、顧客から受けた注文を基に、受注予定の商品引当可能在庫数を本システムに問い合わせる。
・本システムは、受注予定の商品引当可能在庫数を在庫管理サブシステムに問い合わせ、営業担当者に回答する。
・営業担当者は、注文数が引当可能在庫数以下であることを確認し、受注登録を本システムに依頼する。
・本システムは、在庫管理サブシステムの在庫引当処理を実行し、対象商品の引当可能在庫数から注文数を減算する。
・本システムは、販売管理サブシステムの受注登録処理を実行し、受注データを登録する。
〔本システムの受注処理の設計〕
L社の情報システム部のM君が本システムによる受注処理について検討を行い、図2に示す本システムにおける受注処理のシーケンス図を作成した。

M君の上司のN主任が、図2のシーケンス図をレビューし、ACID特性の観点から次の二つの指摘をした。
指摘1:図2の⑧が失敗した場合、受注データとひも付かない在庫引当処理が行われたことになる。この場合、トランザクションのaが保証されない。
指摘2:営業担当者が受注処理を行っている途中で、別の営業担当者が在庫データを照会すると、在庫引当処理が行われる前の時点の引当可能在庫数が参照されることがある。この場合、トランザクションのbが保証されない。
M君は N主任からの指摘に対して、受注処理中に在庫引当処理が行われる前の時点の引当可能在庫数が参照されたとしても、L社の業務上問題にならないと考えた。N主任から指摘2への対処は不要であるとの承認を受け、指摘1についてだけ対応を検討することにした。
〔2相コミット〕
M君は N主任の指摘1に対応するために、2相コミットの考え方を利用し、二つのデータベースの内容を更新するトランザクション内で矛盾が発生しないよう整合性の確保を行った。
本システムは、販売管理サブシステム及び在庫管理サブシステムに対して、更新準備、コミット、ロールバックの3種類の2相コミットインタフェースを使ってデータベースの更新を行う。2相コミットインタフェースの処理概要を表1に示す。

図3は、図2の⑤以降の処理で、2相コミットインタフェースを使った場合のシーケンス図である。

M君は N主任に図3のシーケンス図について再レビューを受けたところ、次の助言をもらった。
前回の指摘1について2相コミットを適用しても完全に解決することはできない。例えば、本システムは、コミット要求又はロールバック要求に対して在庫管理サブシステムと販売管理サブシステムの両方からOK回答を受け取らなかった場合には、①自動的に回復できない状態が発生しているおそれがある。そのときは、アラームを発してその対処をオペレータに促すよう、運用上の対処が必要となる。
さらに、N主任からの助言を基に、M君は、トランザクションの整合性を確認するために、受注処理の流れについて机上検証を行った。その結果、②図3の※1の時点で、本システムに障害が発生した場合に、トランザクション上の問題が起きることを発見した。
設問1:
本文中のa、bに入れる最も適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:隔離性
イ:可用性
ウ:原子性
エ:信頼性
オ:耐久性
カ:保守性
模範解答
a:ウ
b:ア
解説
解答の論理構成
- ACID 特性とは、データベーストランザクションが満たすべき4要件 ― 原子性・一貫性・隔離性・耐久性 ― を総称したものです。
- 問題文には次の指摘があります。
- 「図2の⑧が失敗した場合、受注データとひも付かない在庫引当処理が行われたことになる。この場合、トランザクションのaが保証されない。」
- 「営業担当者が受注処理を行っている途中で、別の営業担当者が在庫データを照会すると、在庫引当処理が行われる前の時点の引当可能在庫数が参照されることがある。この場合、トランザクションのbが保証されない。」
- 指摘1は「在庫引当処理だけ成功・受注登録は失敗」という“途中まで成功”の状態です。ACID のうち「全部成功するか全部失敗するか」の性質は「原子性」です。解答群の「ウ:原子性」が該当します。
- 指摘2は「他トランザクションから途中経過が見える」問題です。ACID の「他の処理からの独立性」を示す性質は「隔離性」です。解答群の「ア:隔離性」が該当します。
- よって
- a=「ウ:原子性」
- b=「ア:隔離性」
誤りやすいポイント
- 「一貫性」と「原子性」を取り違える
一貫性は“整合ルールを破らないこと”、原子性は“オール・オア・ナッシング”であり、更新の片寄りが起こる場面では原子性が問われます。 - 「隔離性」を“排他制御の有無”と短絡的に捉える
実際には“コミット完了までは他トランザクションから見えない”という性質まで含むため、本問のような「途中で読まれる」例は隔離性の欠如です。 - 耐久性(永続性)を想起してしまう
「障害後もデータが消えない」のが耐久性であり、本問のシナリオとは別概念です。
FAQ
Q: 原子性と一貫性は同時に破綻しないのですか?
A: 多くの場合セットで影響しますが、本問は「在庫だけ更新された」時点で整合ルールは破られるため、一貫性も損なわれます。ただし設問は“どの ACID 用語が最も直接的に表すか”を問うており、“全部成功か全部失敗か”を指す原子性が正答になります。
A: 多くの場合セットで影響しますが、本問は「在庫だけ更新された」時点で整合ルールは破られるため、一貫性も損なわれます。ただし設問は“どの ACID 用語が最も直接的に表すか”を問うており、“全部成功か全部失敗か”を指す原子性が正答になります。
Q: 隔離性欠如によって在庫数が誤っていても業務上問題にならないとありますが?
A: L社の業務ルールでは“確定在庫”は引当後にしか参照しないなどの運用があると考えられます。したがって本試験では“技術的には隔離性が満たされないが業務影響は小さい”という前提で対処不要と判断したストーリーです。
A: L社の業務ルールでは“確定在庫”は引当後にしか参照しないなどの運用があると考えられます。したがって本試験では“技術的には隔離性が満たされないが業務影響は小さい”という前提で対処不要と判断したストーリーです。
Q: 2相コミットを使っても原子性が完全保証されないのはなぜ?
A: 「コミット要求又はロールバック要求に対して…両方からOK回答を受け取らなかった場合」に示されるように、通信断やシステム障害が起こると片方の DB だけ確定する可能性が残るためです。この残留リスクを運用(オペレータ介入)で補うのが一般的です。
A: 「コミット要求又はロールバック要求に対して…両方からOK回答を受け取らなかった場合」に示されるように、通信断やシステム障害が起こると片方の DB だけ確定する可能性が残るためです。この残留リスクを運用(オペレータ介入)で補うのが一般的です。
関連キーワード: ACID特性、原子性、隔離性、2相コミット、トランザクション制御
設問2:
図3中のc〜gに入れる適切な字句を答えよ。
模範解答
c:在庫データ
d:更新準備
e:受注データ
f:コミット
g:ロールバック
解説
解答の論理構成
-
2相コミットでやり取りする対象データ
問題文には「二つのデータベースの内容を更新するトランザクション内で矛盾が発生しないよう整合性の確保を行った。」とあり、図3では
・在庫管理サブシステム側 … 在庫を減算する更新
・販売管理サブシステム側 … 受注を登録する更新
の二系統を並列に扱います。したがって
c=「在庫データ」
e=「受注データ」
となります。 -
フェーズ名の決定
表1には 2 相コミットインタフェースの三つの要求が原文そのまま列挙されています。
・「更新準備要求を受け取ると…“更新準備中”と呼ぶ。」
・「コミット要求を受け取ると…更新を確定」
・「ロールバック要求を受け取ると…更新データを破棄」
図3のシーケンスでも最初に送るのはロックと整合性を確保するフェーズなので d=「更新準備」。
成功パスで続くフェーズは確定処理なので f=「コミット」。
失敗パスで送るフェーズは取り消し処理なので g=「ロールバック」。 -
以上を整理すると
c:「在庫データ」
d:「更新準備」
e:「受注データ」
f:「コミット」
g:「ロールバック」
誤りやすいポイント
- 「在庫データ」と「在庫引当処理」を混同し、データ名ではなく処理名を書いてしまう。
- フェーズを“準備”“確定”“中止”など曖昧な日本語で答えて減点される。表1の文言「更新準備」「コミット」「ロールバック」をそのまま引用する必要があります。
- d と f を逆にするミス。2相コミットは “準備 → コミット” の順序と覚えましょう。
FAQ
Q: 2相コミットの「更新準備」でデータをディスクに書くのに、なぜコミットが必要なのですか?
A: 「更新準備」で書き込むのは一時領域です。コミットが到着した時点で初めて本表領域に反映し、ロックを解除します。これにより複数 DB 間で確実に同時確定できます。
A: 「更新準備」で書き込むのは一時領域です。コミットが到着した時点で初めて本表領域に反映し、ロックを解除します。これにより複数 DB 間で確実に同時確定できます。
Q: 図3の※1時点で障害が発生した場合、どのような運用対処が必要ですか?
A: 本システムが「コミット要求又はロールバック要求に対して…OK回答を受け取らなかった場合には、①自動的に回復できない状態が発生しているおそれがある」と明記されています。監視アラームでオペレータに通知し、手動で両 DB の状態を確認・整合させる運用手順を整備します。
A: 本システムが「コミット要求又はロールバック要求に対して…OK回答を受け取らなかった場合には、①自動的に回復できない状態が発生しているおそれがある」と明記されています。監視アラームでオペレータに通知し、手動で両 DB の状態を確認・整合させる運用手順を整備します。
Q: 指摘2(分離性)の対処を省いても業務上問題がないのはなぜですか?
A: 営業担当者が参照する在庫は“引当可能在庫”であり、多少のずれがあっても後続の在庫引当で正しくロックされるため、L社の受注業務では許容できると判断されたためです。
A: 営業担当者が参照する在庫は“引当可能在庫”であり、多少のずれがあっても後続の在庫引当で正しくロックされるため、L社の受注業務では許容できると判断されたためです。
関連キーワード: 2相コミット、ACID特性、分散トランザクション、ロック制御、ロールバック
設問3:
本文中の下線①について、どのような状態が発生した場合に、自動的に回復できないデータの不整合が発生するのか。解答群の中から全て選び、記号で答えよ。
解答群
ア:在庫データの更新が失敗し、受注データの登録が成功した状態
イ:在庫データの更新が失敗し、受データの登録も失敗した状態
ウ:在庫データの更新が成功し、受注データの登録が失敗した状態
エ:在庫データの更新が成功し、受注データの登録も成功した状態
模範解答
ア、ウ
解説
解答の論理構成
- 問題文では、2 相コミットの第 2 フェーズで
「コミット要求又はロールバック要求に対して在庫管理サブシステムと販売管理サブシステムの両方からOK回答を受け取らなかった場合には、①自動的に回復できない状態が発生しているおそれがある。」
と述べています。
― 両方から “OK” が返らない = 片方だけが更新を確定させ、もう片方は確定できない(またはロールバックしてしまう)状況です。 - 2 相コミットの “コミット” の処理概要(表1)では
「更新準備中にコミット要求を受け取ると、更新データをデータベースに書き込んだ後、更新を確定してOK回答を返す。」
とあり、OK が返ったときは更新が完了しています。 - したがって、
・「在庫管理サブシステム」が OK、しかし「販売管理サブシステム」が NG
・逆に「販売管理サブシステム」が OK、しかし「在庫管理サブシステム」が NG
のいずれもデータが片側だけ確定し、整合が取れなくなります。 - 解答群と照合すると
ア:在庫データの更新が失敗し、受注データの登録が成功した状態
ウ:在庫データの更新が成功し、受注データの登録が失敗した状態
が該当します。 - よって正答は「ア、ウ」です。
誤りやすいポイント
- 「両方成功したとき」や「両方失敗したとき」は整合が保たれることを見落とし、イやエを選んでしまう。
- 2 相コミットの “更新準備” と “コミット” を混同し、更新準備で NG が返るケースまで ① の対象と誤解する。
- ACID の “原子性” を「常に同時に成功する」と短絡的に覚え、片方成功・片方失敗の危険性を具体的に想像しない。
FAQ
Q: 「両方失敗」でもトランザクションはロールバックできていますか?
A: はい。両システムとも更新されていないため、整合性は保持されます。問題文の ① は “片方だけ” 成功する状況を指します。
A: はい。両システムとも更新されていないため、整合性は保持されます。問題文の ① は “片方だけ” 成功する状況を指します。
Q: “コミット要求” ではなく “ロールバック要求” でも同じ危険がありますか?
A: あります。ロールバック要求に対し片方が OK・片方が NG でも、やはり片側が更新済みになるおそれがあり、① と同様の不整合になります。
A: あります。ロールバック要求に対し片方が OK・片方が NG でも、やはり片側が更新済みになるおそれがあり、① と同様の不整合になります。
Q: 2 相コミットで完全に安全と思っていました。なぜ不整合が残るのですか?
A: フェーズ 2 で障害が発生すると、コーディネータ(本システム)が結果を統一できないまま停止する可能性があります。このとき各サブシステム間で状態を照合できず、不整合が残ることがあります。
A: フェーズ 2 で障害が発生すると、コーディネータ(本システム)が結果を統一できないまま停止する可能性があります。このとき各サブシステム間で状態を照合できず、不整合が残ることがあります。
関連キーワード: 2相コミット、原子性、ロールバック、データロック、トランザクション整合性
設問4:本文中の下線②の問題について(1)、(2)に答えよ。
(1)この状態で在庫データと受注データにどのような問題が発生するか。15字以内で述べよ。
模範解答
ロックされたままとなる。
解説
解答の論理構成
- 図3の流れでは、⑦までに本システムが「在庫管理サブシステム」と「販売管理サブシステム」からともに OK を受領し、両データベースは**“更新準備中”**となります。
引用:表1「更新準備要求を受け取ると、…当該データのロックを行う(この状態を“更新準備中”と呼ぶ)。」 - “更新準備中”ではロックが掛かったままで、まだコミット/ロールバックは実行されていません。次に送る予定だったのが**f要求(コミット)またはg要求(ロールバック)**です。
- しかし下線②「図3の※1の時点で、本システムに障害が発生した場合」に該当すると、
・コミットもロールバックも送信できない
・したがってロック解除処理も動かない
という状態になります。 - その結果、後続トランザクションはロック競合で待たされ続け、整合性は保たれるものの業務が停止します。
- よって「在庫データと受注データに発生する問題」は
ロックされたままとなる
となります。
誤りやすいポイント
- 「部分更新が残る」と誤解しがちですが、まだコミットしていないのでデータ内容は書き換わっていません。問題はロック保持です。
- 2相コミット=万能と考え、障害復旧や運用監視を設計から漏らすケース。
- “更新準備中”と“コミット済”を混同し、ロック解除のタイミングを取り違える失点が頻発します。
FAQ
Q: なぜロックが解除されないと業務が止まるのですか?
A: “更新準備中”のレコードは排他ロック中です。以後の参照・更新要求は待機またはタイムアウトとなり、在庫照会や新規受注が処理できなくなります。
A: “更新準備中”のレコードは排他ロック中です。以後の参照・更新要求は待機またはタイムアウトとなり、在庫照会や新規受注が処理できなくなります。
Q: 自動的にロールバックさせればいいのでは?
A: 表1「ロールバック要求を受け取ったときに更新準備中になっていない場合は、何もせずにNG回答を返す。」とあり、要求メッセージが届かなければ自動実行されません。外部からの指示か再起動処理が必要です。
A: 表1「ロールバック要求を受け取ったときに更新準備中になっていない場合は、何もせずにNG回答を返す。」とあり、要求メッセージが届かなければ自動実行されません。外部からの指示か再起動処理が必要です。
Q: どのACID特性が守れなくなるのですか?
A: 原子性・一貫性は崩れていませんが、可用性(実務観点)に影響します。試験の設問は「発生する問題」を問うており、回答はロック残存です。
A: 原子性・一貫性は崩れていませんが、可用性(実務観点)に影響します。試験の設問は「発生する問題」を問うており、回答はロック残存です。
関連キーワード: 2相コミット、排他ロック、原子性、更新準備、障害回復
設問4:本文中の下線②の問題について(1)、(2)に答えよ。
(2)この問題の対応方法のうち最も適切なものを解答群の中から選び、記号で答えよ。
解答群
ア:在庫管理サブシステムが販売管理サブシステムにコミット要求を出す。
イ:在庫管理サブシステムが販売管理サブシステムにロールバック要求を出す。
ウ:販売管理サブシステムと在庫管理サブシステムがタイムアウトを検出してロールバックする。
エ:販売管理サブシステムと在庫管理サブシステムが本システムからの口ールバック要求又はコミット要求を待つ。
模範解答
ウ
解説
解答の論理構成
-
問題で示された障害シナリオ
- 本文には、
「②図3の※1の時点で、本システムに障害が発生した場合に、トランザクション上の問題」
とあります。 - ※1 は「更新準備(OK)」を両サブシステムから受け取った直後、すなわち 2 相コミットのフェーズ 1 が終了し、フェーズ 2(コミット/ロールバック指示)がまだ送られていない瞬間です。
- 本文には、
「②図3の※1の時点で、本システムに障害が発生した場合に、トランザクション上の問題」
-
フェーズ 1 で停止すると何が起こるか
- 表1 によれば、更新準備中は「当該データのロックを行う」と定義されています。
- したがって統合販売管理システムがダウンすると、
• 在庫管理サブシステム
• 販売管理サブシステム
いずれも“更新準備中”のロックを保持したままコミット/ロールバックの指示を待つ状態になります。
-
必要な対処とは
- コーディネータ(統合販売管理システム)が復帰しない可能性を考慮すると、データベースが半永久的にロックされることは許容できません。
- よって各サブシステムが一定時間 “更新準備中” のままになったことを自律的に検知し、自動的にロールバックしてロックを解除する仕組みが必要です。
- これが選択肢「ウ:販売管理サブシステムと在庫管理サブシステムがタイムアウトを検出してロールバックする。」に相当します。
-
他の選択肢が不適切な理由
- ア/イ:在庫管理サブシステムが勝手に販売管理サブシステムへ指示を送ると、コーディネータ不在で意思決定が二重化し、2 相コミットの役割分担(調停者と参加者)が崩れます。
- エ:コーディネータが復旧しない限りロックが解除されず、業務が停止し続けるため現実的ではありません。
-
結論
- 上記より、最も適切なのは「ウ」となります。
誤りやすいポイント
- 「2 相コミットなら ACID が完全保証される」と思い込み、コーディネータ障害時の“インドウトランザクション”を見落とす。
- フェーズ 1 のロックを「短時間だから問題ない」と過小評価し、長時間ダウン時の業務停止リスクを考慮しない。
- 参加者同士が直接コミット/ロールバックをやり取りする案(ア・イ)を選び、プロトコルの役割分担違反に気付かない。
FAQ
Q: タイムアウトはどのくらいの時間に設定すべきですか?
A: システムの可用性要件と取引量に応じて決定します。一般には「コーディネータのフェイルオーバ時間+安全余裕」を目安にします。
A: システムの可用性要件と取引量に応じて決定します。一般には「コーディネータのフェイルオーバ時間+安全余裕」を目安にします。
Q: コーディネータ復旧後の再送処理は必要ですか?
A: はい。復旧後に“更新準備中”データが残っていないかログを照合し、必要に応じてコミット/ロールバックを補完する回復機構が求められます。
A: はい。復旧後に“更新準備中”データが残っていないかログを照合し、必要に応じてコミット/ロールバックを補完する回復機構が求められます。
Q: タイムアウトによる自動ロールバックでデータ不整合は起きませんか?
A: フェーズ 1 ではまだどの DB も確定更新していないため、全参加者がロールバックすれば一貫性は保たれます。不整合は発生しません。
A: フェーズ 1 ではまだどの DB も確定更新していないため、全参加者がロールバックすれば一貫性は保たれます。不整合は発生しません。
関連キーワード: 2相コミット、タイムアウト、インドウトランザクション、ロック制御、コーディネータ


