クラスタ全体でJava同期ブロックを共有するか、グローバルロックを使用しますか？

Question

私は1つのスレッドだけがアクセスを許可するコードをいくつか持っています。私は​​ブロックまたはメソッドを使用してこれを達成する方法を知っていますが、これはクラスタ化された環境で動作しますか？

ターゲット環境はWebSphere 6.0で、クラスタ内に2つのノードがあります。

​​は、各ノード上のアプリケーションの各インスタンスが独自のJVMを持つため、うまくいかないと感じています。

私がここでやろうとしているのは、システムの起動時にデータベースレコードを更新することです。コードのバージョンより古いデータベースレコードを検索し、特定のタスクを実行して更新します。 1つのノードでこれらのアップグレードを実行したいのは、各作業項目が1回だけアップグレードされ、アップグレードのパフォーマンスが大きな問題ではないことです。なぜなら、アプリケーションの起動時に発生するためです。最後に起動してからコードが変更されたとき。

データベースはDB2v9であり、JNDI（ORM層なし）を介して直接アクセスしています。

グローバルロックがここに行く方法かもしれないことが示唆されていますが、その方法はわかりません。

誰でもこのアリーナにポインタを持っていますか？

ありがとうございます！

Answer 1

Java同期構造を使用して、プロセス間の同期が機能しないことは間違いありません。幸いにも、あなたの問題は実際にはコード同期の1つではなく、データベースとの相互作用を同期させることです。

この問題に対処する正しい方法は、データベースレベルのロックです。おそらく、あなたはdbスキーマバージョンを含むいくつかのテーブルを持っているので、起動/アップグレードプロセスの間、そのテーブルを確実にロックする必要があります。

データベースタイプ（DB2？）とアクセスメソッド（raw sql、jpaなど）を指定すると、正確なsql/db呼び出しがより明確になります。

更新（2009年8月4日14:39）：私は、スキーマのバージョン番号を保持しているいくつかのテーブルの上にLOCK TABLE文を示唆しています。これにより、そのテーブルへのアクセスがシリアライズされ、2つのインスタンスが同時にアップグレードコードを実行することが防止されます。

Answer 2

テーブル（またはデータベース全体）を更新するだけでロックできないので、最初のノードがロックを取得したときに、他のすべてのノードが書き込むことができなくなります。後続のノードは待機し、ロックが解除されるとコードは更新されるため、レコードの更新は必要ありません。

Answer 3

はい、あなたは正しくブロックがクラスタを越えて動作しないという点で正しいです。理由は、あなたが述べたように、各ノードには独自のJVMがあるからです。

ただし、単一ノード環境で動作するように、クラスタ内で同期化されたブロックを動作させる方法があります。最も簡単な方法は、Terracottaのような製品を使用することです。これは、異なるJVM間のスレッドの調整を処理し、通常の同時実行制御をクラスタ全体で使用できるようにします。 Introduction to OpenTerracottaのように、これがどのように機能するかを説明する記事がたくさんあります。

他の解決策はもちろんあります。これは、あなたが実際にここで達成したいものに大きく依存します。 DBのように、スケールする必要がある場合は、同期のためにデータベースロックを使用しません。しかし、私は実際には、クラスタ同期をめちゃくちゃにすることは面倒なビジネスであるため、既成のソリューションを見つけることを強く勧めます。

Answer 4

2台のマシンについて話しているので、共有メモリもなく、 。

私たちのデータベースと似たようなことを行います。これは、テーブルにレコードのバージョンを追加することによって実現されます。これはあなたがすべきことです。

1. レコード/行バージョンの列を追加します。
2. レコードを更新する必要があるかどうかを確認するロジックを実行します。
3. レコードを更新するときは、DBのレコードバージョンが所有しているものと同じであることを確認してください。
4. データベースに書き込むたびにバンプアップします。

これらのルールに従うと、データベースを更新するサーバーは1つだけにしてください。

Answer 5

http://www.hazelcast.com/のようなメモリ内データグリッドを使用することもできます。これは、ロックをサポートする分散データ構造です。