問題タブ [pessimistic-locking]

現在、Grails 2.4.4 でクレジット取引システムを開発しています。

ユーザーのクレジットの量を保持するクレジット モデルがあります。

問題は、ユーザーが取引するときに、金額が常に引き落とされたり貸方に記入されたりすることです。

整合性を維持するために悲観的ロックを試みました。しかし、そのユーザーは一度に 1 つのトランザクションしか実行できないため、トランザクションのボトルネックであることに気付きました。

これに代わるものはありますか？使用できる設計パターンはありますか? 私たちは、モデルを変更したり、他のアプローチを採用したりすることにオープンです。

SQL Server を使用して WinForms 保険見積もりアプリケーションに悲観的ロック パターンを実装することを検討しています。ユーザーが見積もりの​​作業を開始する前に、レコードがロック テーブルに追加されます。完了すると、レコードはテーブルから削除されます。

私の質問は、アプリケーションの制御の及ばない障害が発生した場合にロックが解放されるようにするにはどうすればよいですか? 私は主にクライアント側のネットワーク接続エラーまたは電源障害について考えていますが、無限の可能性があります。

コントローラーに次のコードがあります。

しかし、コードを実行するとエラーが発生します:

古いオブジェクトを更新しようとしました: アイテム

理由がわかりません。レールのドキュメントに従いました。

「楽観的同時実行制御」と呼ばれることもある「楽観的ロック」には、実際にはロックがないことを学びました。典型的な実装は CAS (Compare-And-Swap) です。ロックがなくても、なぜこれがまだ「楽観的ロック」と呼ばれているのでしょうか。この用語がデータベースの世界に由来するという歴史的な理由はありますか?

最近、私はデータベーストランザクションを研究しており、次のような記事の引用があります。

JPA は、@Version アノテーションを介して行のバージョン管理の自動サポートを提供します。 @Version アノテーションが付けられたフィールドまたはプロパティを持つエンティティがある場合、楽観的ロックが自動的に有効になります。

私の理解では、データベースの分離レベル戦略は、次のようなさまざまなロックを使用して維持されます

1. コミットされていない読み取り: 排他的書き込みロックで実装
2. 読み取りコミット: 共有読み取りロックと排他的書き込みロックを使用して実装されます。

すぐ。したがって、トランザクションの分離は、悲観的ロックを使用して推測される別のロックによって実装されます。

私の質問は、フィールドが @Version 注釈付きとして宣言されている場合、それは基になるデフォルトの分離レベルをオーバーライドし、楽観的ロックが行われるのですか?

lockforupdate を正しく使用/テストする方法を理解しようとしていますが、期待どおりに機能しないことがわかりました

これはただのテストです

私は2つのブラウザでテストしようとします。ブラウザ1のユーザーがログインし、ブラウザ2がログインしていない場合、ブラウザ1が更新をヒットすると、更新のためにロックされ、更新の60秒前にスリープします

60 秒以内にブラウザー 2 に移動して更新を押しますが、レコードはロックされていません。phpmyadmin を確認すると、レコードが更新されます (ブラウザー 1 による 60 秒のロック トリガー内)。

しかし、60 秒後に、レコードはブラウザ 1 によって再び変更されました (ポイント 100000)

だから私は lockforupdate が何のために使用されているのか誤解していますか?それとも間違ってテストしていますか?

私が期待したのは、最初の 60 秒間にブラウザー 2 によって行が変更されるべきではないということです (ファビコンまたはエラースローをロードする空白のページですか?)

https://laravel.com/docs/5.2/queries#pessimistic-locking

私はいくつかの調査を行いましたが、まだsharedLock(LOCK IN SHARE MODE)とlockForUpdate(FOR UPDATE)の違いを理解できません

ところで、データベースがinnodbであることを確認しました

JPA 2.1仕様によると...

ロック モードPESSIMISTIC_READ、PESSIMISTIC_WRITE、および PESSIMISTIC_FORCE_INCREMENTは、長期データベース ロックを即座に取得するために使用されます。

SELECT ... FOR UPDATEどのロックモードが使用されていても、悲観的ロックは常にデータベースで SQL をトリガーすると思います。それについて3つの質問があります：

1. 仮定は正しいですか、それとも正しい場合、この規則からの例外はありますか?
2. 行がSELECT ... FOR UPDATEロックされているとします。ロックされた行は、それをロックしたトランザクション以外のトランザクションによって更新できませんか?
3. ロックは、トランザクションに対してコミットまたはロールバックを実行することで解放できます。アプリケーション (および行をロックしたトランザクション) が、トランザクションでコミットまたはロールバックを実行せずに突然終了した場合、ロックはどうなりますか?

トランザクション A:

トランザクション B:

これらのトランザクションがほぼ同時に実行されると、デッドロックが発生する可能性がありますか?

クエリは複数の結果を返すことが期待されています。

その下で、結果を1つずつロックしているのではないかと考えていましたが、順序が指定されていないため、異なる順序でロックが発生し、デッドロックが発生する可能性があります。

これは可能ですか？