0

4 つのクローンを持つ WebSphere クラスターがあります。各クローンで同一のコードが実行されます。コードを実行するジョブを Quartz に定期的に開始させます。

このコードは、クローンの 1 つだけがテーブルを正常に更新できるように、テーブル内の行を更新しようとします。その後、そのクローンが残りのジョブを実行します。何かのようなもの：

update <table> set status = 'RUNNING' where job_name = 'JOB1' and status = 'STOPPED'

update ステートメントを実行するときにトランザクションを開始しません。

4 つのクローンすべてがテーブルの更新に失敗し、すべてロック タイムアウト エラー (SQL コード -913) が発生することがあります。

また、トランザクションを開始し、行が実行中としてマークされているかどうかを選択して確認し、そうでない場合は更新を実行してコミットするという代替手段も試しました。それ以外の場合はロールバックします。

それには同じ問題がありました。

まだ試していない解決策の 1 つは、select を「select for update」に変更することです。

助言がありますか？

4

1 に答える 1

0

これは結果として問題にはなりませんでした (これは、自分で確認せずに誰かの話を聞いた結果です)。

2 つのクローンを使用して開発環境でこれをテストしました。クローンの 1 つで -913 ロック タイムアウト エラーが発生することがありましたが、他のクローンではテーブルが正常に更新されていました。見苦しいログ メッセージ以外は、すべて正常に機能しました。

ただし、通常、-913 エラーは発生せず、クローンの 1 つから更新する行がないことを示す警告が表示されます。繰り返しますが、この動作は問題ありません。

したがって、私たちが最初に考えたように、Clockwork-Muse も提案しているように、この方法で UPDATE ステートメントを使用してロックを適用すると、DB2 で問題なく機能します。

于 2013-03-05T14:35:23.547 に答える