一部の mysql 接続では、削除と挿入の後に mysql データベースの古いデータが選択されるのはなぜですか?

Question

Python/wsgi Web アプリケーションのセッションで問題が発生しています。 2 つの wsgi デーモンの各スレッドには、異なる永続的な mysqldb 接続があります。場合によっては、古いセッションを削除して新しいセッションを作成した後も、一部の接続で古いセッションが選択されたままになることがあります。これは、セッションの認証に失敗し、再度ログインを要求することを意味します。

詳細: セッションは、ローカルの mysql データベースの InnoDB テーブルに保存されます。 (CAS 経由で) 認証した後、そのユーザーの以前のセッションをすべて削除し、新しいセッションを作成し (行を挿入)、トランザクションをコミットし、Cookie の新しいセッション ID を使用して最初に要求されたページにリダイレクトします。リクエストごとに、Cookie 内のセッション ID がデータベース内のセッションと照合されます。

リダイレクト後に、新しく作成されたセッションがデータベース内に見つからない場合があります。代わりに、ユーザーの old セッションはまだ存在します。 (各リクエストの開始時にすべてのセッションを選択してログに記録することで、これを確認しました)。どういうわけかキャッシュされた結果が得られます。 SQL_NO_CACHE を使用してセッションを選択しようとしましたが、違いはありませんでした。

キャッシュされた結果が得られるのはなぜですか?他にどこでキャッシュが発生する可能性がありますか?また、キャッシュを停止またはキャッシュをフラッシュするにはどうすればよいですか?基本的に、なぜ他の接続は新しく挿入されたデータを見ることができないのでしょうか?

Answer 1

はい、トランザクションを 1 つだけ実行して切断することを想定しているようです。異なるニーズがある場合は、この仮定に対処する必要があります。 @a_horse_with_no_name が述べたように、コミットできます (ただし、実際にデータを変更しなかった場合はロールバックを使用します)。または、カーソル上の分離レベルを変更することもできます - このディスカッション から、私はこれを使用しました:

dbcursor.execute("コミットされたセッションのトランザクション分離レベルを設定します")

あるいは、接続上で autocommit を true に設定できるようです:

dbconn.autocommit(True)

ただし、実際に接続を変更する場合、これはお勧めできません。

Answer 2

MySQL のデフォルトの分離レベルは「REPEATABLE READ」です。これは、たとえ (他の) 変更がコミットされたとしても、トランザクションの開始後に行われた変更は表示されないことを意味します。

これらのセッションで COMMIT または ROLLBACK を発行すると、変更されたデータが表示されます (これにより「進行中の」トランザクションが終了するため)。

もう 1 つのオプションは、これらのセッションの分離レベルを「READ COMMITTED」に変更することです。デフォルトのレベルを変更するオプションがある場合もありますが、マニュアルを確認する必要があります。