データベース駆動型アプリケーションでロックを実装する（より簡単な）方法はどのようにあるのか疑問に思っています（たとえば、c＃で、データベース操作を処理するWCF / Webサービスに接続するすべてのデスクトップアプリケーションまたはWebアプリケーションを参照します）。
この wiki 記事http://en.wikipedia.org/wiki/Lock_(computer_science ) から、前回の読み取り以降に更新が行われたかどうかを確認し、それに応じてエラーをスローし、ユーザーに再読み取りを求める楽観的ロックを実行できることを理解していますデータを再度更新してください。ただし、同時に更新を行うユーザーの数が多い場合、更新の試行錯誤が多くなる可能性があるという欠点があります。
結論として、楽観的ロックはオプションだと思います。実装が複雑ではない他のオプションはありますか? ロックとミューテックスはオプションだと思いますが、「if」条件を実装してどのレコードがブロックされているかを確認し、デッドロックを引き起こさないようにする方法は考えられません。
データをロックする簡単な方法は、次のような列を持つ単純なテーブルをデータベースに作成することです。
列 1: テーブル名 列 2: 行 ID 列 3: ロック (ブール値) すべてのソフトウェアがこのテーブルを読み取って、どのレコードが変更されているかを認識できるようになった後。
使用している、または検討しているデータベース製品については言及していません。PostgreSQL には (それがオプションである場合)、Optimistic Concurrency Control (OCC) に似た手法がありますが、SERIALIZABLEトランザクションに使用されるロールバックが少なくなります。これは、Serializable Snapshot Isolation (SSI) と呼ばれます。基本的に、OCC は単一の読み取り/書き込み反依存関係に基づいてトランザクションをキャンセルしますが、SSI は複数の読み取り/書き込み反依存関係のパターンがある場合にのみトランザクションをキャンセルします。効果が可能です。
これは、2008 年に学術論文で初めて公開された新しい手法であり、2011 年にリリースされた PostgreSQL 9.1 の公開本番データベースに初めて登場しました。
もちろん、この問題に取り組む方法は他にもたくさんありますが、OCC に興味を持っているということは、これがあなたにとって魅力的である可能性があることを示唆しているようです。同時トランザクションに直面して整合性を維持するすべての手法には、ブロック、トランザクションのロールバック、またはその両方が含まれます。「従来の」厳密な 2 フェーズ ロック (S2PL) 手法はブロッキングに傾いていますが、OCC と SSI はブロッキングが最小限 (したがって同時実行性が高い) ですが、一部のワークロードではロールバックが大幅に増加する可能性があります。使用する最善の手法は、間違いなくワークロードに依存します。
SSI の詳細については、SERIALIZABLE トランザクション分離レベルのPostgreSQL ドキュメント、いくつかの例を含む Wiki ページ、ACM SIGMOD 2008 の最初の論文、Michael J. Cahill の博士論文、 Dan RK Ports と私自身による論文を参照してください。これは VLDB 2012 でのプレゼンテーションが承認されており、間もなく VLDB によって公開される予定です。
デッドロックを回避することは、正しい順序でロックを取得することです。たとえば、ある特定のユーザーのデータを変更する前に、そのユーザーを UPDLOCK して、同時トランザクションがそのユーザーを同時に変更できないようにすることができます。
これはほんの一例です。一貫した順序でロックを取得する可能性が非常に高いスキームを見つける必要があります。
読み取りには、スナップショット分離を使用できます。
いずれにせよ、多くのアプリケーションでは特定の場所でのみデッドロックが発生します。ほんの少しのコードを変更するだけで、問題を無視して、本番環境での誤ったデッドロックを修正できるかもしれません。