この質問は、saga データが Azure Table Storage に永続化されている場合の、saga データへの同時アクセスに関するものです。また、Particular のドキュメントにある情報も参照しています: http://docs.particular.net/nservicebus/nservicebus-sagas-and-concurrency
ハンドラーを同時に実行している 1 つのサガ内で、サガ データへの変更は、"azure テーブル ストレージに変更をポストする最後の変更が優先される" シナリオで動作しているように見えることに気付きました。NSB を Azure Table Storage と組み合わせて Saga データの永続化レイヤーとして使用する場合、これは意図された動作ですか?
例：
- Saga Data の整数プロパティ、現在 = 5 と仮定
- このサガでは、5 つのコマンドが同じハンドラーの 5 つのインスタンスによって処理されます
- 各コマンド ハンドラーは、サガ データの整数プロパティをデクリメントします。
- サガ データの整数プロパティの最終値は、これらの 5 つのメッセージを処理した後、実際には 4 になる可能性があります。各メッセージがサガの新しいインスタンスによって処理された場合、異なるサーバー上にある可能性があり、それぞれが整数プロパティが 5 であることを示すサガ データのコピーを持っています。 、それを 4 にデクリメントし、ポスト バックアップします。今説明したのは非常に同時実行の例ですが、5 つのメッセージのいずれかが同時に処理された場合、整数が 0 より大きくなる可能性があります。サガ データの整数プロパティが 0 に達するのは、5 つのコマンドがたまたま実行されたときだけです。連続して。
また、Azure Table Storage は Optimistic Concurrency をサポートしているため、Raven を永続化テクノロジとして使用する場合に RavenDB で有効にするのと同じように、Table Storage でこの機能を使用できるようにすることは可能ですか?
これが不可能な場合、これを処理するための推奨されるアプローチは何ですか? 現在、複数のメッセージを同時に処理する可能性のある saga 内のハンドラーは、saga データを変更できないというパラダイムにサブスクライブしています。つまり、saga メッセージの調整は、saga データを使用するのではなく、saga の外部の手段を介して行われます。当初の意図どおりです。