Maison  >  Questions et réponses  >  le corps du texte

Pourquoi certaines connexions MySQL sélectionnent-elles les anciennes données de la base de données MySQL après suppression+insertion ?

Je rencontre des problèmes avec les sessions dans mon application Web python/wsgi. Chaque thread des 2 démons wsgi a une connexion mysqldb différente et persistante. Parfois, après avoir supprimé l'ancienne session et en avoir créé une nouvelle, certaines connexions obtiennent toujours l'ancienne session dans la sélection, ce qui signifie qu'elles ne parviennent pas à authentifier la session et demandent à se reconnecter.

Détails : les sessions sont stockées dans une table InnoDB dans une base de données MySQL locale. Après m'être authentifié (via CAS), je supprime toutes les sessions précédentes de cet utilisateur, crée une nouvelle session (insère une ligne), valide la transaction et redirige vers la page initialement demandée en utilisant le nouvel ID de session du cookie. Pour chaque demande, l'ID de session dans le cookie est comparé à la session dans la base de données.

Parfois, les sessions nouvellement créées ne sont pas trouvées dans la base de données après la redirection. Au lieu de cela, l'anciennesession de l'utilisateur existe toujours. (J'ai vérifié cela en sélectionnant et en enregistrant toutes les sessions au début de chaque demande). D'une manière ou d'une autre, j'obtiens des résultats en cache. J'ai essayé d'utiliser SQL_NO_CACHE pour sélectionner la session mais cela n'a fait aucune différence.

Pourquoi est-ce que j'obtiens des résultats en cache ? Où d'autre la mise en cache peut-elle avoir lieu et comment puis-je l'arrêter ou vider le cache ? Fondamentalement, pourquoi les autres connexions ne peuvent-elles pas voir les données nouvellement insérées ?

P粉882357979P粉882357979355 Il y a quelques jours757

répondre à tous(2)je répondrai

  • P粉696891871

    P粉6968918712023-10-31 10:19:28

    Oui, il semble que cela suppose que vous n'effectuerez qu'une seule transaction, puis que vous vous déconnecterez. Si vous avez des besoins différents, vous devez alors tenir compte de cette hypothèse. Comme @a_horse_with_no_name l'a mentionné, vous pouvez vous engager (même si j'utiliserais la restauration si vous n'aviez pas réellement modifié les données). Ou vous pouvez modifier le niveau d'isolement sur le curseur - à partir de cette discussionJ'ai utilisé ceci :

    dbcursor.execute("设置会话事务隔离级别读取已提交")

    Alternativement, il semble que vous puissiez définir l'autocommit sur true sur la connexion :

    dbconn.autocommit(True)

    Cependant, cela n'est pas recommandé si vous apportez réellement des modifications à la connexion.

    répondre
    0
  • P粉545956597

    P粉5459565972023-10-31 09:25:48

    Niveau d'isolement par défaut de MySQL "REPEATABLE READ", ce qui signifie que vous ne verrez aucune modification apportée après le démarrage de la transaction - même si ces (autres) modifications ont été validées.

    Si vous émettez un COMMIT ou un ROLLBACK au cours de ces sessions, vous devriez voir les données modifiées (car cela mettra fin à la transaction "en cours").

    Une autre option consiste à changer le niveau d'isolement de ces sessions en "READ COMMITTED". Il peut également y avoir une option pour modifier le niveau par défaut, mais vous devrez consulter le manuel.

    répondre
    0
  • Annulerrépondre