このロックはアプリケーション レベルであり、異なる mysql セッション間で使用されます。これは単なる名前ロックであり、テーブル、行、フィールドとは直接の関係はありません。特定のロックは完全にアプリケーションに委ねられます。これは排他ロックです。つまり、どのセッションがロックを保持しても、他のセッションがロックを取得しようとすると失敗します。
たとえば、レコード A の行をロックする場合は、現在のセッション get_lock("record A", 10) にロックを作成します。現時点では、他のすべてのセッションは、明示的に get_lock("record A", 10) を呼び出さない限り、レコード A に自由にアクセスして変更できます。
このロックはアプリケーション レベルであり、異なる mysql セッション間で使用されます。これは単なる名前ロックであり、テーブル、行、フィールドとは直接の関係はありません。特定のロックは完全にアプリケーションに委ねられます。これは排他ロックです。つまり、どのセッションがロックを保持しても、他のセッションがロックを取得しようとすると失敗します。
たとえば、レコード A の行をロックする場合は、現在のセッション
get_lock("record A", 10)
にロックを作成します。現時点では、他のすべてのセッションは、明示的にget_lock("record A", 10)
を呼び出さない限り、レコード A に自由にアクセスして変更できます。つまり、ロックをチェックするかどうかを決定するのは完全にアプリケーション次第です。ロックしたい場合は、レコード A にアクセスするときにすべてのセッションが明示的に
を再取得できます。get_lock("record A", 10)
を呼び出すようにします。そうすると、明らかに 1 つのセッションのみが成功します。他のセッションは、タイムアウトを待つか、ロックを保持しているセッションによってrelease_lock
を呼び出した後にのみ、ロック同様に、フィールド列 A をロックする場合は、上記のようにロック
get_lock("column A", 10)
を作成します。つまり、ロックを取得するかどうかを決定するのはアプリケーション次第であり、データベースはこのメカニズムを提供するだけです。全員が同じロックを取得しているかどうかを確認するには、最初のパラメータであるロック名が異なる文字列であるという事実にのみ基づいているため、ロック名の前にテーブル名とデータベース名を追加するのがベスト プラクティスです。偶発的な損傷を避けるため