Considérations relatives à la réutilisation d’une session ou d’une connexion entre plusieurs threads¶

Effets de la réutilisation d’une session ou d’une connexion sur plusieurs threads¶

Les utilisateurs de pilotes créent souvent des applications multithreads. Plutôt que de créer des sessions et des connexions distinctes pour chaque thread, vous pouvez essayer d’économiser des frais généraux en réutilisant une session ou une connexion dans différents threads. Sachez que cela peut entraîner les comportements indésirables suivants :

• État de la session

  Les sessions gardent un suivi de la base de données, du schéma et du rôle actuels. Si un thread modifie ces valeurs (comme USE DATABASE), l’autre thread peut être affecté. Cet impact est particulièrement important car le passage à un autre schéma comportant les mêmes tables peut amener un thread à modifier accidentellement la mauvaise table. En outre, la modification des paramètres de connexion ou de configuration dans une session peut affecter toutes les threads qui utilisent cette session.

• État de la transaction

  Une transaction peut commencer au cours d’une session. Si plusieurs threads ont accès à cette session, chacun d’entre eux peut potentiellement modifier les données dans la même transaction, ce qui peut entraîner la persistance accidentelle des données ou leur perte si une transaction est validée ou annulée.

• Compteur de séquences

  Les pilotes utilisent un compteur de séquences pour relancer les requêtes. Les compteurs de séquences étant globaux pour une session, la réutilisation d’une session dans différents threads peut également modifier par inadvertance le compteur de séquences global, ce qui peut entraîner un comportement imprévisible lors de la relance des requêtes.

• Cache du contexte de la requête

  Pour améliorer les performances, les sessions gardent un suivi de certaines informations internes dans un cache interne ou spécifique au pilote. Le cache est mis à jour après chaque requête, de sorte que l’exécution simultanée de plusieurs requêtes au cours d’une session peut entraîner une corruption des données.

• Dernière requête ID

  Les connexions gardent le suivi de l’ID de la dernière requête, qui peut alors être récupérée et utilisée. Si deux requêtes sont exécutées en parallèle dans des threads différents, une condition de course peut affecter celui qui définit l’ID de la dernière requête.

Recommandations Snowflake¶

• Utilisez des pools de connexions dans la mesure du possible.

  Si vous réutilisez des connexions entre plusieurs threads pour éviter de devoir vous authentifier fréquemment, vous devez envisager d’utiliser des pools de connexions. L’utilisation de pools de connexions réduit le nombre de demandes d’authentification, car la session n’est pas fermée à la fin - elle est simplement renvoyée dans un pool où elle est prête à être utilisée à la prochaine occasion. Même si vous utilisez des pools de connexions, votre application doit veiller à ne pas modifier ou réinitialiser des paramètres qui n’affectent qu’une requête spécifique ou une base de données en cours. En outre, l’application est responsable de la réalisation ou de l’abandon des transactions actives avant de renvoyer une connexion au pool de connexions.

• Utilisez les requêtes asynchrones avec prudence.

  Le lancement simultané de plusieurs requêtes asynchrones sur une même connexion, ou le lancement d’une requête synchrone alors qu’une requête asynchrone est toujours en cours, peut donner lieu à une condition de course susceptible d’entraîner des résultats imprévisibles.

• Utilisez des optimisations supplémentaires en matière d’authentification.

  Des pilotes spécifiques prennent en charge tout ou partie des optimisations suivantes, que vous pouvez utiliser pour améliorer les performances de l’authentification :

  • Caches de jetons SSO

  • Caches de jetons MFA

  • Jetons dans les fichiers de configuration TOML

  • Accesseurs de jetons personnalisés

  Vous devez consulter la documentation du pilote pour savoir lesquelles de ces options sont prises en charge par le pilote.

• Désactivez la mise en cache du contexte de requête.

  Si vous êtes conscient de tous les problèmes liés à la réutilisation des sessions et des connexions dans plusieurs threads, mais que vous souhaitez tout de même les utiliser, Snowflake vous recommande de désactiver la mise en cache des requêtes en définissant le paramètre DisableQueryContextCache sur false dans la définition de la connexion.