これにより、MySQL (InnoDB) との競合状態が発生しますか?
取引開始。
レコードを取得してみてください。
レコードが存在しない場合は、戻ります。
レコードが存在する場合は、それを削除し、削除されたことを示すログ エントリを追加します。
トランザクションの終了 (コミット/ロールバック)。
2b の削除ステップの直前に別のプロセスを開始し、レコードの存在を検出してから、両方のプロセスに項目削除エントリをログに入力させることは可能ですか?
私が取る必要がある予防措置はありますか？
ありがとう。
ステップ2で「select for update」を使用します。1つのプロセスのみが行のロックを取得できるため、説明したシナリオを回避できます。
取引開始。
レコードを削除 /* 「レコードの取得を試みる」の場合とまったく同じ基準を使用して */
応答がレコードが実際に削除されたことを示している場合は、ログ エントリを追加します。
トランザクションの終了 (コミット/ロールバック)。
競合状態はもうありません。
はい、テーブルを読み取った後、別のトランザクションがテーブルをチェックする可能性があります。
さらに悪いことに、トランザクションの仕組みにより、行を削除した後でも、まだ削除をコミットしていないため、開始された新しいトランザクションには行が表示されます。
SELECT ... FOR UPDATE防ぐ方法の一つです。
LOCK TABLE tablename別のものです。
残念ながら、あなたは ORM を使用しているため、これらのいずれかを実行できるかどうかはわかりませんでした。