私たちのアプリケーションのうちの1つは、すぐに大幅な負荷の増加が予想され、既存のデータベースのボトルネックを解消するために、Hazelcast分散コレクションを評価しています。JMS、データベース、およびHazelcast分散コレクションを含むXAトランザクション
アプリケーションの複数のインスタンスが、複数の異なるホスト上で水平方向のスケーリングのために実行されています。アプリケーションのさまざまなモジュールが複数のWebshere Application Serverにデプロイされ、複数のJVMに負荷が分散されます。典型的な作業の流れがで成る：
- のメッセージがWebshere MQキューからMDBにプッシュされます
- MDBは、メッセージを解析し、MDBは、特別なメッセージから抽出データベース
- に保存します関連するメッセージを識別するキーを生成し、そのキーを特別なロッキングテーブルに挿入します。そのようなキーがノードによって取得されると、そのノード上のすべての関連メッセージを処理します。関連するすべてのメッセージを順番に処理することは、アプリケーションにとって非常に重要です。 このテーブルは、ヘイルキャストブロッキングキューに置き換えたいものの1つです。
- 同じMDBがWebshere MQトピックで通知を送信し、他のJVMに、処理が到着したことを通知します。 我々は他のJVMが通知を受け取るたら、ロック・テーブル・エントリが利用可能であることは確かであるので、上記のすべてのフローが同じXAトランザクションに起こる
Hazelcastトピックに置き換えるが、これはオプションです
受信したJVMが通知を受け取ると、ロックテーブルにジャンプしてキーをロックし、そのキーに属するすべてのメッセージを処理します。常にメッセージが流れているので、実行中のすべてのJVMがキーを取得できる状態になっています。
複数のスレッドがキーを同時にロックしようとしているため、データベースがアプリケーションの全体的なパフォーマンスに影響を与え始めていることがわかりました。
シーケンス処理を制御するセマフォーテーブルはいくつかありますが、これはインメモリデータグリッドに移動すると考えられます。
上記はかなり私達の話です。理論的には良いアイデアのように思えますが、必ずしもパフォーマンスが向上するとは思えません。なぜなら、少なくとも1つのリソースに負荷をかけることによって、ネットワークトラフィックが減少するからです。
JMS、DB、およびHazelcastコレクションが含まれるXAトランスナショナル・コンテキストをセットアップする方法について、Googleに試しました。残念ながら、XAに関するHazelcastのドキュメントは、ほんの数行のコードであり、それ以上のものはありません。私はこの問題に直面している唯一の人ではないと確信しており、ここでいくつかの入力を希望します。実用的な解決策は必要ありません。良い例へのリンクや、私を動かすためのドキュメンテーションのヒントがあれば十分でしょう。
https://github.com/hazelcast/hazelcast/tree/master/hazelcast/src/test/java/com/hazelcast/xa
また、いくつかのコードサンプルがここにあります： https://github.com/hazelcast/hazelcast-code-samples/tree/master/transactions
私はこれまでに見ました。これらはすべて、ヘイルキャストのインスタンスのみを含みます。私が後にしているのは、さまざまな種類のリソースでXAトランザクションを実行する方法を理解することです。データベースとヘイルキャストインスタンスがあり、トランザクションの一部としてデータベースにレコードを挿入し、分散キューにエントリを追加するとします。コミットが発生した場合にのみ、キューエントリは、別のJVMで実行されている第2のハローキャストインスタンスで使用できるようにする必要があります。データベースエントリと同じです。 – Julian
JTXAとHazelcastリソースアダプタ（https://github.com/hazelcast/hazelcast-ra）を使用する場合、Hazelcastはあらゆるタイプのトランザクションを含むことができるJTXAトランザクション全体の一部になります。 – noctarius
@noctarius私はそれを受け入れることができるように答えとして投稿してください。 – Julian