私が関与しているアプリケーション用に簡単なレコード ロックを開発することを考えていました。レコードの編集を完了するのに文字通り何時間もかかるユーザーが何人かいます。これにより、他の誰かがレコードを変更したい場合に問題が発生します。現在、関連するロックはありません。

レコードは AJAX リクエストを介して保存されるため、私の場合、楽観的ロックが信頼できるかどうかはわかりません。ある種の悲観的ロックの適用を検討しています。locked_user_idとlocked_timestampなどの 2 つのフィールドを使用して、レコードを開いているユーザーと最後に開いた時刻を追跡できます。

しかし、ユーザーは一度に何時間も開いている可能性があるため、ユーザーがそれを放棄したのか、それとも一生懸命取り組んでいるのかをどうやって知ることができますか? 5分ごとに更新するように強制したくありませんが、それは可能かもしれません（AJAXは5分ごとに保存します）。

おそらく、ユーザーが作業している間、jQuery プロセスがカウントし、5 分ごとに AJAX リクエスト (getJSON) を起動して、locking_timestamp を更新する可能性があります。そうすれば、誰がレコードに取り組んでいるかを維持できます。タイムスタンプが「古く」なった後、ユーザーはレコードを使用しなくなったと推測できます。この種のロックを経験した人はいますか？

私はAzureキャッシングが初めてで、1つの問題に直面しています。

最初にシナリオについて簡単に説明します。SQL AzureアプリケーションのDBとして使用しています。待機時間の問題とスロットリングの問題を回避するために、Azure キャッシュ (Web ロールのコロケーション キャッシュ) を使用しています。Azure Caching を使用することで、DB からデータを 1 回だけフェッチし、それをキャッシュに保持して後で使用できるようにします。

キャッシュされたデータを使用しているため、ここでの課題は、DML 操作が実行されるたびに、いつでも SQL Azure DB と Azure キャッシュの間でデータを常に同期させることです。最初にDBを更新し、更新が成功した場合はキャッシュされたデータを無効にすることでこれを行っています。このアプローチは、通常のシナリオではうまく機能します。ただし、同時ユーザーが作業して更新を実行していると、問題があるようです。キャッシュ内のデータを更新する際に、悲観的同時実行モデルを使用しています。ここでは、一時的な再試行ポリシーを使用して再試行を確実に行います (1 秒の固定間隔で 5 回としましょう)。

サンプル コードは次のようになります。

ここで、待機回数 (6 としましょう) が再試行回数 (この場合は 5) を超えた場合を考えます。6 番目の順番になるまでに、再試行の試行はすでに終了しているため、最新の更新がある 6 番目の Wait はキャッシュでの更新に失敗します。

この問題を解決するには、キャッシュ キーのロックを取得している間にerrorcodeすべての待機をキューに入れる方法があります。objectlocked

誰でもこのケースを処理する最善の方法を提案できますか?

私は、Azure Shared Cachingを使用して、サーバー側のWebサーバーのキャッシングレイヤーに取り組んでおり、データベースへの要求の量を減らして、処理を高速化します（うまくいけば）。私が立ち往生しているのは、スレッド全体を安全にする方法です。DataCacheでキーをロックするための信頼できる使用可能な方法が見つからないようです。私が見逃しているのは、何かが格納される前にキーを事前にロックする方法です。これにより、別のスレッドが同じことを同時に実行しようとするリスクなしに値を追加できます。

私はこれまで悲観的なロックだけに注目してきました。それがスレッドセーフが私にとって最も理にかなっている方法なので、私が取り組んでいるものがロックされていることを確認したいと思います。

悲観的ロックを使用する場合、私はそれに関連するメソッドのみを使用する責任があることを理解しました。物事を混ぜると、ロックメカニズム全体が台無しになります（ソース：http：//go4answers.webhost4life.com/Example/datacacheput-unlocking-key-77158.aspx）。

問題は、まだキャッシュにないものを取得しようとすると、「GetAndLock」が例外をスローすることです。同時に、キャッシュに何かを追加するための私の唯一の方法は「PutAndUnlock」であり、「GetAndUnlock」を成功させない限り、その方法を使用することはできません。

事実上、キャッシュに新しいものを追加することは不可能です。実行できるのは、すでに存在するものを置き換えることだけです（これは何もありません）。

したがって、「GetAndLock」が例外をスローしない場合は、楽観的な「Put」を使用せざるを得ないように思われます。しかし、私が読んだことによると、楽観的な「Put」は「GetAndLock」で達成された既存のロックをすべて破壊するため、スレッドセーフの試み全体が破壊されます。

基本的に、2つのスレッドは、両方が持っていると考えているロックを無視して、同じキーに同時に異なるものを書き込むことができます。

私の唯一の結論は、DataCacheの悲観的なロックは機能が不完全であり、完全に使用できないということです。私は何かが足りないのですか？これを解決する方法はありますか？

私が見逃しているのは、キーに何かが保存される前に、キーを事前にロックする方法だけです。

Java EEを使用しています。そして、最悪の場合、多数のメッセージ キュー メッセージが同じユーザーから送信されるアプリケーションを作成しています。

したがって、悲観的な SELECT FOR UPDATE スタイルのロックを検討しています。理論と最初のテストでは、これが問題を解決します。

しかし、私たちはデッドロックを恐れています。古典的なものではありません: ユーザー X は A をロックし、ユーザー Y は B をロックします。原因不明のデータベース システムのロック。Oracle、MS SQL、postgresql などの最新のデータベースを使用します。

私たちが知りたいのは、本番環境で使用される悲観的ロックと、予想される実際の問題は何ですか?

前もって感謝します！

2つ質問があります。

1. Lightswitch 2011は悲観的同時実行制御もサポートしていますか? もしそうなら、どのように？
2. 楽観的制御は、外部データ ソースからのテーブルの ROWVERSION 列をサポートしていますか、それとも行の状態のみを使用しますか (元の値を使用)?

返信ありがとうございます。

悲観的ロックを処理する PHP/MySQL/jQuery コードの問題をデバッグしようとしています。これは、locking_user_id と locked_date_time の 2 つのフィールドを使用します。ロックは、PHP/MySQL に対する AJAX アクションによって決定されます。以下の jQuery コードは、15 秒ごとに発生するロックの典型的な更新を示しています。10 分ごとに保存アクションもあります。

私の質問は、誰かのコンピューターが「スリープ モード」になるか、数時間「ロック」された場合、jQuery/Locking Update はどうなりますか? AJAX 呼び出しは続行されますか? setTimeout() が実行されなくなったと思いますか? 編集ビューを何時間も開いたままにしておくことを意図的に許可している人がいます。これが問題の原因であると確信しています。今日、更新時に追加の PHP 検証チェックを組み込んでいます。

非アクティブに基づいて編集ビューを「タイムアウト」にするための提案はありますか?

関連記事: PHP/MySQL/jQuery のレコードの悲観的ロック

以下に示すように、別のエンティティを「モニター」として使用して、同時コンテキストで SomeEntity の新しいインスタンスを作成する必要があるシステムがあります。

Mysql を使用している場合、これは LockOptions.UPGRADE でモニターをロードしているときに発生するロックで完全に機能しますが、HSQLDB を使用している場合、上記のコードは機能せず、すべてのスレッドがデータベース レベルでロックなしで実行され、作成が発生します。データベース内の SomeEntity の多くのインスタンスの。

主な質問

Hibernate と HSQLDB を使用してデータベース レベルでエンティティをロックする必要があります。

例

必要なものを例示するために、2 つの属性 (id と名前) を持つ Person というエンティティ クラスと、1 つのインスタンス (Person#id) に対して同時に name 属性を更新するメイン プログラムを持つ単純なプロジェクトを作成しました。 = 1)。更新のために競合する 3 つのスレッドがあり、すべてが次の命令によってデータベース レベルで同期されます。

上記のコードを一度に 1 つのスレッドだけを使用すると、name 属性が更新され、他のすべてのスレッドはロックの取得を待機します。

ロックが発生した場合、Hibernate によって生成された SQL コードで視覚化でき、次のようになります。

または、session.load(...) が呼び出される行にブレークポイントを設定して、Eclipse IDE でのデバッグ中に視覚化することもできます (1 つのスレッドのみが次の命令に進み、他のすべてのスレッドは待機します)。

したがって、もう一度思い出してください。これは Mysql では機能しますが、 HSQLDB では機能しません。

付属品

「lock:true」で選択された、または後で単にロックされたドメイン オブジェクトがあるとします。ロックを解除せずに状態をデータベースに保存する方法はありますか? (私が理解しているように、デフォルトの動作は save() がロックを解放することです。)

実行中にオブジェクトをロックする必要がある多くの操作を含む長い (時間単位の) 関数がありますが、関数の一部が失敗する可能性があるため、特定の時点で実行中にオブジェクトの状態を保存したいと考えています。

Postgres データベースに対して Hibernate 3 を介して、JPA で悲観的ロックを使用しようとしています。ロックをタイムアウトにできません - 永遠にハングしているようです。

次に例を示します。

私が理解しているように、em2 はロックを取得するために最大 5 秒間 (5000 ミリ秒) 試行し、その後例外をスローする必要がありました。代わりに、コードはデッドロックになります。

これを 2 つの異なるスレッドで実行すると、スレッド 1 (em1) が解放するとすぐにスレッド 2 (em2 を使用) がロックを取得することがわかります。そのため、ロックが発生していますが、タイムアウトすることはありません。

PESSIMISTIC_WRITE や任意のタイムアウト値 (2ms、0ms 'NO WAIT') などでも同じ効果が得られます。

Hibernate 3.6.10 Final (最新の Hibernate 3 バージョン) と Postgres jdbc ドライバー 9.2-1003.jdbc4 (最新のドライバー) を使用しています。Postgres 8.4 データベースに対して実行しています。

私が見つけたすべてのドキュメントは、これが機能することを示唆しています。何か案は？

ありがとう、アラステア