問題タブ [pessimistic-locking]

楽観的ロックと悲観的ロックが何であるかは知っていますが、Java コードを作成するときはどのようにしますか? Java で Oracle を使用しているとします。これを行うのに役立つ JDBC のメソッドはありますか? これをどのように構成しますか？任意のポインタをいただければ幸いです。

異なるコントローラー間で共有される、CakePHP アプリケーションに悲観的ロックを実装しました。基本的に、ページにアクセスすると、レコードがテーブルに書き込まれ、そのモデルのエントリがそのユーザーによって編集されていることがタイムスタンプとともに示されます。ajax 呼び出しで 30 秒ごとに、そのレコードのタイムスタンプが更新され、ページがまだ使用中であることが示されます。誰かがページに入ろうとすると、アクセスが拒否されます。ページが残っている場合、「ロック」はその 30 秒の終わりに期限切れになります。

全体として、クエリは次のとおりです。

• 3 ページがロードされたとき (1 時間以上経過したすべてのロックを削除 (DELETE)、ページがまだ使用されていないかどうかを確認 (SELECT)、使用されていない場合はロックを作成 (INSERT))。
• 2 ロックが更新されたとき (ページがまだロックされていないかどうかを確認します (SELECT)。ロックされていない場合は、ロックのタイムスタンプを更新します (UPDATE))。

これはデータの永続的なストレージではなく（明らかにデータベースを使用する必要があります）、一時的なものであるため、キャッシュシステムを使用する必要があるかどうか疑問に思っています。データベースよりも高速ですか？（しかし、私のキャッシュは単なるファイルキャッシュであるため、よくわかりません）。

SQLServer2000には悲観的な同時実行モデルがあることを私は知っています。また、楽観的なモデルがSQL Server 2005に追加されました。では、SQL Server 2005および2008で悲観的な同時実行モデルを使用しているか、楽観的なモデルを使用しているかをどのように判断すればよいでしょうか。

ありがとう。

MySqlInnoDBが行のロックを取得する方法を明示的に指定したいと思います。これが可能であれば、デッドロックが停止するだけではいけません。（慣例に従う場合。）

まず、データベースはテーブル「モデル」にあるすべての行を昇順でロックする必要があります。次に、2番目のテーブル「colors」のすべての行が昇順でロックされます。最初にテーブルの「モデル」をロックし、次に「色」をロックするようにデータベースを制御する方法はありますか？

たとえば、次のようになります。

Silverlight アプリケーション用の WCF Web サービスを作成しています。変更時に読み取り/書き込みロックされるレコードが必要です。

MySQL バージョン 5.5.11 を使用しています。

具体的には、リクエストが変更中に行からデータを読み取らないようにしたいと思います。

UPDATE と SELECT の 2 つの SQL コマンドは、実際には非常に単純で、次のようになります。

更新（書き込み/読み取りのためにロックする必要があります）：

選択 (上記のクエリからロックされている場合は読み取れないはずです):

これが私が試したものですが、まったく機能しないか、何もロックしていないようです:

分散キー値ストアに悲観的ロックを実装しています。ロックを実装するための堅実なアトミック比較交換 (およびインクリメントとデクリメント) 操作があります。セット、ソート済みセット、リスト、および配列のデータ構造もあり、これらはすでにアトミック操作を提供しています (サーバー側スクリプトを使用して、これらの構造を任意の方法でアトミックに操作できます)。

上記を構成要素として使用して、.Net のWaitHandle.WaitAllのような操作をサポートする再入可能ミューテックスを作成する必要があります。ライブロックや飢餓の可能性を最小限に抑えながら、1 回の呼び出しで複数のリソースをロックできます。それ、どうやったら出来るの？一般的に受け入れられているアルゴリズムはありますか?

副次的な質問として、Peterson のアルゴリズムとその類縁のものを見てきましたが、これらの相互排除アルゴリズムは、私が直面している問題とは異なる問題を解決しているようです (私はすでにアトミック操作を行っています)。私は、より高度な同期プリミティブ ( http://en.wikipedia.org/wiki/Mutual_exclusion#Advanced_mutual_exclusionのタイトルに基づく) と見なされるものに向けて取り組んでおり、別のクラスのアルゴリズムがあるかどうか疑問に思っています。それは、これらの核心の少ない問題に答えます。

ノードの階層を編集するモジュールを構築しています。これは、多くのレベルのネストされたディレクトリとファイルを持つ非常に大きなディレクトリ構造と考えることができます。階層のノードは、リレーショナル データベース テーブルに格納されます。唯一の違いは、フォルダー/ディレクトリのようなものがないことです。すべてのノードは同じ特性を持っています。したがって、ノードにはノードでもある親があります。また、ルート ノードは 1 つしかなく、ノードは親ノードを 1 つしか持てないため、ポリ階層はありません。

表の列:

node_id [bigint] null でない
名前 [nvarchar(50)]
parent_node_id [bigint]
leaf_node [bit]

目標は、ユーザーが互いに足を踏み入れることなく、1 つの階層を編集する方法を見つけることです。バージョン管理アーキテクチャを設計して競合を解決するか、何らかのロック メカニズム (悲観的または楽観的) を使用して、階層全体内の特定の親ノードの祖先 (またはサブツリー) の一部であるノードを他のユーザーが編集できないようにする必要があります。木。ロックを実行すると、エディターを使用しているすべての人が、他のユーザーの変更を確認するためにツリーを常に更新する必要があります。

気になる機能は3つだけ。マスター ツリーでノード/オブジェクトを編集できるのは、1 人のユーザーのみです。新しく作成されたサブツリーをマスター ツリーにドラッグ アンド ドロップします。マスター ツリー内のサブツリーをマスター ツリー内の別のノードにドラッグ アンド ドロップして、ドロップしたサブツリーをそのノードの子にします。

このアーキテクチャは、フォルダとファイルを管理するオペレーティング システムのアーキテクチャと何ら変わりはないと思います。何千人ものユーザーがいる場合、通常はどのように行われますか? バージョン管理を使用して複雑さを軽減するのではなく、ロックメカニズムを使用したいと思います。最善のアプローチが何であるかはわかりません。

これまでの私の計画は次のとおりです。

• ノードが編集されている場合は、保存が行われ、データベースがレコードを更新しようとするまでノードをロックしないでください。データベースが変更を行ったら、ロックを解除します。データベースが変更を行っているのとまったく同じタイミングで他の誰かがレコードを編集しようとした場合、ロックされていることをユーザーに伝えないでください。データベースにレコード/ノードのロックを処理させます。

• 新しいサブツリーがマスター ツリーの親ノードにドラッグされている場合は、新しい親をロックします。次に、新しいレコードを挿入し、マスター ツリーの親ノードを指すようにルートの親を更新します。次に、マスター ツリーを更新するようにすべてのクライアントに通知します。したがって、ドロップが発生した後、すべてのロックはデータベース側で行われます。

• 既存のマスター ツリーの親ノードが既存のマスター ツリーの親ノードにドラッグされ、子ノードになる場合は、古い親 (新しい子になる) をロックし、新しい親をロックする必要があります。次に、新しい子の親ノードを更新します。次に、すべてのクライアント (すべてのユーザー) を更新し、マスター ツリーを更新します。したがって、ドロップが発生した後、すべてのロックはデータベース側で行われます。

私たちのアプリは主に、Hibernate のバージョン管理サポートを使用した楽観的ロックを使用しています。特定のシナリオで悲観的ロックを実装する予定です。私は悲観的ロックの経験があまりないので、この質問がナイーブに聞こえる場合はご容赦ください。

ユーザーがエントリを更新する意図を示した場合、「select for update」を使用して対応する DB 行をロックします。さて、このユーザーが変更をコミットするのに長い時間がかかり、ロック後にそれを忘れてしまった場合、タイムアウト/ロールバック メカニズムを使用してこのロックを解除するにはどうすればよいでしょうか? 行が非常に長い間ロックされたままになり、他のすべてのユーザーがその行を編集できなくなることがないようにします。

これが、私たちが使用している Weblogic-JTA-Spring トランザクション メカニズムで処理されるかどうかは疑問です。ここでは、既に 30 分のトランザクション タイムアウトがあります。(??)

したがって、このロールバックは Oracle レベルで直接処理する必要があります。はいの場合、どのように？このようなロックが長く残りすぎないように、これを処理する最善の方法についてアドバイスしてください。

私はのためのサービスを実装しました、entity objectそしてそれは純粋を使用しますjpa、私は使用springしました、それでimplとしてspring xml config構成されました。運用にデータを使用しています。しかし、私たちのシステムでは、オブジェクトが何度もプル/更新されており、データとの競合が高くなっています。多くの場所のコードから、エンティティを取得するためのサービスBeanと呼び出しメソッドだけが多く、その後、エンティティが変更されます（これは私の理解では切り離されていますが、同じスレッドであるため、emオブジェクトは私の知識と同じである必要があります）そのため、エンティティがサービスに戻って更新されるまでしばらく時間がかかり、サービスのメソッドを呼び出してエンティティを保存します。メソッドはただ呼び出すだけですhibernatejpaspringcrudentityconcurrencyclassesinjectgetEntitysave()Save()merge()Crud操作。@Transactional注釈付きのトランザクションです。ここで問題が発生します。誰かがエンティティオブジェクトをプルし、それを変更しているときに他の誰かがそれをプルして変更して保存し直す可能性があるため、エンティティの読み取りがダーティであり、保存すると、すでに更新されたエンティティを上書きします。問題は、サービスの外部でエンティティを変更し、savebackを呼び出すことです。ここで、春のデータリポジトリクラスはDAOレイヤーです。

Optimistic lockは1つの解決策ですが、何らかの理由で気に入らなかったため、機能しません。私は考えていpessimistic lockます。たとえば、ロックして更新するエンティティを取得し、それを別の場所に変更してコールバックすると（entity更新に対してすでにロックされています！）、機能しますか？EntityManagerエンティティをプルするために使用したオブジェクトがまだそこにあるかどうかはわかりません。そこにある場合、更新されてロックが解除される前に、これらの「スマート」ロジックを渡すのに非常に長い時間がかかります。

シナリオの簡単なサンプルコードは次のとおりです。

ここでtons of logicは、それをサービスレイヤー内に移動することはできません。これは非常に具体的であり、この種のさまざまなロジックは数百の場所にあります。

それで、回避して、少なくともこの状況に悲観的なロックを適用する方法はありますか？