私が使用したいSAGAの私の春ブーツMicroservicesにパターンを。たとえば、順序は次のように、イベントを作成し、顧客のため、中OrderCreatedEventに顧客microserviceでリスナーを作成し、OrderCreatedEvent更新、顧客の信用と生産CreditUpdateEventと...を。
私は、トランザクションセッションを使用JmsTemplateイベント製造するために。javadocのJmsTemplateJMSトランザクションがメイン・トランザクションの後にコミットすることを言いました：
これは、JMSトランザクションがメイン・トランザクションの後に右をコミットすると、（ネイティブJDBCトランザクションであるかもしれない）、メイン・トランザクションと一緒に管理されているローカルのJMSトランザクションの効果があります。
今、私の質問は、私はシナリオの下に扱うことができる方法です。
メイン・トランザクションがコミット（例えば順序がコミットrecored）とシステム（何らかの理由で）JMSトランザクションをコミットすることができませんでした。
私はコミットの代わりに2つの相のSAGAを使用したいが、私はちょうどSAGAが注文サービスとJMSプロバイダへの注文と顧客サービスの問題を移動すると思います。
SAGAは、問題をヒント：
アドレスに以下の問題もあります。
...
- 信頼できるためには、サービスはアトミックにそのデータベースを更新する必要がありますし、イベントを公開します。これは、データベースとメッセージブローカにまたがる分散トランザクションの伝統的なメカニズムを使用することはできません。代わりに、それは、下記のパターンのいずれかを使用する必要があります。
...
次のパターンは、アトミック状態を更新し、イベントを公開する方法があります。
- イベントソーシング
- アプリケーションイベント
- データベース・トリガー
- トランザクションログのテーリング
イベントソーシングは、それがどのようにシステムを格納およびプロセスデータに根本的な変化をもたらすとして、このリストでは特別です。通常、システムは、エンティティの現在の状態のみを格納します。一部のシステムでは、有効期間および/またはとの歴史的な状態のための明示的なサポートを追加しbitemporalデータ。
イベントソーシングに基づいているシステムでは、イベントから状態を再構築することを可能にする方法で、代わりにエンティティ状態のイベントのシーケンスを格納します。イベント・ストア - - 維持する唯一のトランザクションリソースがありますので、トランザクションを調整する必要はありません。
（エンティティとして）エンティティの状態とイベントの両方 - - 単一のデータストアにリスト内の他のパターンは、すべての変更をコミットするイベントプロデューサのコードを必要とすることによって、トランザクション調整の問題を回避します。その後、専用の、しかし別のメカニズム - イベント・パブリッシャーは、 - データストアからイベントを取得し、イベントコンシューマに公開するために実装されています。
イベント発行者は、通常、バック整合トランザクションの問題をもたらし、公開/未公開のイベントを追跡する必要があります。のであったこと、イベント消費者の冪等は光に来ます。消費者は、重複を無視しながら、イベントの出版社は、最後の既知の位置からイベントを再生します。
また、イベントのプロデューサーとイベント・コンシューマーのアクティブ/パッシブの面を反転させてもよいです。単一のデータ・ストアにイベントプロデューサ記憶エンティティの状態（エンティティとして）イベント及びアクセスイベントストリームにイベントコンシューマを可能にするエンドポイントを提供します。それは冪等の理由から、とにかくやる必要がある- -各イベントの消費者は、処理/未処理のイベントを追跡しますが、唯一のイベントのためにそれが約興味を持っているストリーム。このアプローチの本当に良い説明は本の中で与えられている実践でREST -第7章と第8章。