1

MongoDBのドキュメントで説明されているように、MongoDBの2フェーズコミットを実装しました。基本的に、これは正常に機能します。私が気にしているのは新しいドキュメントを挿入することだけなので、特に簡単でした。更新することはありません。

それでも、これを解決する方法がわからない特定のシナリオについて心配しています。だからどんな助けもいただければ幸いです。

指定：次の構造のドキュメントを含むコレクション：

id: ...,
subId: ...
payload: {
  ...
}

同じドキュメントが複数存在する場合がありますが、同じidドキュメントはすべてid増加していsubIdます。だから、あなたは次のようなものを持っています：

  • 1-1
  • 1-2
  • 2-1
  • 3-1
  • 3-2
  • 3-3

各挿入は1つだけを扱いidますが、複数のドキュメントを提供する可能性があります。つまり、これは、ドキュメントと。を含む挿入が存在する可能性があることを意味しますが、3 - 4ドキュメント3 - 5と。を含む3 - 4挿入は存在しない可能性があり4 - 1ます。

およびフィールドはid、subIdクライアントがデータを挿入することによって計算されます。

複数のドキュメントを挿入する場合、この挿入は2PCでカバーされます。したがって、すべてのドキュメントがコミットされるか、まったくコミットされません。

この問題は、2PCの第2フェーズで発生します。他のクライアントがコミットされていないデータを読み取れるようにしたくないので、各ドキュメント内に、ドキュメントがすでにコミットされているかどうかを示すフラグがあります。すべてのドキュメントが書き込まれ、トランザクションが「完了」に設定されると、最後のステップとして、ドキュメントはコミット済みとしてマークされます。

したがって、挿入しようとする3 - 4と3 - 5、両方が書き込まれ、トランザクションが完了し、コミット済み3 - 4としてマークされ、コミット済みとしてマークされる直前に3 - 5、別のクライアントがidを持つすべてのドキュメントを読み取り3、subId4を最高のものと見なし、新しいドキュメントと3 - 5それを挿入しますか？

その後、コミットが失敗し、2つのトランザクションのバージョン番号が混在しています。

これを解決する方法は？

4

1 に答える 1

0

ああ、忘れて…「書くと見える」という典型的なケース。私が説明したシナリオは3 - 5、最初のトランザクションによってすでに作成されているので問題ありません。コミットされていないだけです。したがって、別のトランザクションには一意のインデックス制約があるため、id - subId干渉することはできません。

問題が解決しました。

于 2012-09-29T08:34:30.157 に答える