テーブルの行ロックについてまだ混乱しています。私は MySQL/PHP を使用しています。これが私のシナリオです。
アプリケーションがリクエストと投稿を追跡するために使用する一連のテーブルがあります。ユーザは、アイテム (テーブル ITEM (I)) の投稿 (テーブル POSTING (P)) を作成し、個々のユーザに要求を送信したり (テーブル REQUEST (R))、投稿して投稿応答を受信したり (テーブル POSTING_RESPONSE (PR) ））ユーザー投稿アイテムによって受け入れられます。
例: 私は自転車のユーザーです。私はそれを投稿し、個々のユーザーにリクエストを送信します。私からのリクエストを受け取ったユーザーは、受け入れる/拒否する/何もしないことができます。彼らが受け入れる場合 - それは予約されています。他のユーザーは私の投稿を見つけて、アイテムに「応募」できます。私には、彼らの要求を「受け入れる」または「無視する」能力があります。私が受け入れると、アイテムは予約されます。
誰かがリクエストを受け入れたらやりたいこと：
item に対応する ITEM (I) テーブルの行をロックする
項目に対応する POSTING (P) テーブルの行をロックします (行が存在する場合)。
アイテムに対して送信されたすべての要求に対して、REQUEST (R) テーブルの行をロックします
item に対応する POSTING_RESPONSE (PR) テーブル (行が存在する場合) の行をロックします
ITEMステータスを「予約済み」に更新
POSTING ステータスを「利用不可」に更新する
すべて/任意の POSTING_RESPONSE を「拒否済み」に更新します
受け入れたリクエスト以外のすべてのリクエストを「拒否」に更新 - そのリクエストを「受け入れ」に更新
この例でのステータスの重複は無視してください。
ここで、#1 - 4 は、単純な "select ... for update" を実行して、AUTOCOMMIT を false のままにできると想定しました。これらの select ステートメントを使用して、更新する必要があるかどうかを判断できます。必要な場合は、更新を続行できます。次に、更新 #5 ～ 8 の完了後、コミットして行のロックを解除します。
これを機能させるのに問題があります。それが私がしていることによるものなのか、それとも私の考えが間違っているためなのかはわかりません。
もう 1 つ...アイテムのステータスを EXPIRED または CANCELLED に更新できる他のプロセスがあります。私のアプローチに対する唯一の解決策は、考えられるすべての条件を UPDATE ステートメント内の WHERE 句に入れることではないことを願っています...これは簡単に保守できません。