レコードのロックに関して、私たちのチームに推奨される設計パターンを考え出そうとしています。典型的な考え方は次のようになります: 1. ユーザーがリストからレコードを選択する 2. ユーザー ID でレコードをロックする 3. ロックされたレコード レコードをロードする (ロックなしで、誰かがあなたを打ち負かす)。
何か不足していますか、それともこれが唯一の方法のように見えますか? ((私たちの場合、オプティミスティック ロックは、エンド ユーザーにとって面倒で混乱を招きます。多くの場合、編集は非常に重要です。))
ソリューションの管理を集中的にする詳細は、クラッシュまたは接続障害の後にロックを解除することです。楽観的ロックと悲観的ロックの間のトレードオフが実際にあるのはここです。楽観的ロックが失敗したときに手動で編集をマージまたはやり直すのは苦痛ですが、悲観的および永続的ロック モデルでクラッシュした後に修正することは、それ自体が頭痛の種になります (90 年代に Pervasive に裏打ちされた会計システムのユーザーをサポートした人なら誰でも、与えられた詳細を教えてくれるでしょう)。チャンス）
1 つの答えは、トランザクションと同時実行性を管理するために RDBMS のメカニズムを使用することです。SELECT FOR UPDATE または環境と分離レベルに適した構文を使用してレコードを取得します。クライアントのいずれかがクラッシュまたは切断された場合、トランザクションはロールバックされ、ロックが解除されます。
Web のようなコネクションレス環境や、接続が頻繁に失われて回復する環境では、セッション タイムアウトを使用したセッション ベースのモデルも機能します。
したがって、セッションの有効期限が切れるとロックが解除されます。クラッシュ後にロックを手動で削除する必要がなく、クライアント/接続の問題に対するある程度の耐性。ただし、コーディングにはもう少し手間がかかります。