Regroupement de connexions du gestionnaire de pilotes

Connecter regroupement d’applications permet à une application d’utiliser une connexion à partir d’un pool de connexions qui n’ont pas besoin d’être rétablies pour chaque utilisation. Une fois qu’une connexion a été créée et placée dans un pool, une application peut réutiliser cette connexion sans effectuer le processus de connexion complet.

L’utilisation d’une connexion mise en pool peut entraîner des gains de performances significatifs, car les applications peuvent économiser la surcharge liée à la création d’une connexion. Cela peut être particulièrement important pour les applications de niveau intermédiaire qui se connectent sur un réseau ou pour les applications qui se connectent et se déconnectent à plusieurs reprises, comme les applications Internet.

En plus des gains de performances, l’architecture de regroupement de connexions permet à un environnement et à ses connexions associées d’être utilisées par plusieurs composants dans un seul processus. Cela signifie que les composants autonomes du même processus peuvent interagir entre eux sans être conscients les uns des autres. Une connexion dans un pool de connexions peut être utilisée à plusieurs reprises par plusieurs composants.

Remarque

Connecter le regroupement d’Connecter peut être utilisé par une application ODBC présentant ODBC 2.comportement x, tant que l’application peut appeler SQLSetEnvAttr. Lorsque vous utilisez le regroupement de connexions, l’application ne doit pas exécuter d’instructions SQL qui modifient la base de données ou le contexte de la base de données, telles que la modification du <nom> de la base de données, ce qui modifie le catalogue utilisé par une source de données.

Un pilote ODBC doit être entièrement thread-safe, et les connexions ne doivent pas avoir d’affinité de thread pour prendre en charge le regroupement de connexions. Cela signifie que le pilote est en mesure de gérer un appel sur n’importe quel thread à tout moment et est en mesure de se connecter sur un thread, d’utiliser la connexion sur un autre thread et de se déconnecter sur un troisième thread.

Le pool de connexions est géré par le Gestionnaire de pilotes. Connecter ions sont tirées du pool lorsque l’application appelle SQL Connecter ou SQLDriver Connecter et sont retournés au pool lorsque l’application appelle SQLDisconnect. La taille du pool augmente dynamiquement en fonction des allocations de ressources demandées. Elle diminue en fonction du délai d’inactivité : si une connexion est inactive pendant une période de temps (elle n’a pas été utilisée dans une connexion), elle est supprimée du pool. La taille du pool est limitée uniquement par les contraintes de mémoire et les limites sur le serveur.

Le Gestionnaire de pilotes détermine si une connexion spécifique dans un pool doit être utilisée en fonction des arguments passés dans SQL Connecter ou SQLDriver Connecter, et selon les attributs de connexion définis après l’allocation de la connexion.

Lorsque le Gestionnaire de pilotes met en pool des connexions, il doit être en mesure de déterminer si une connexion fonctionne toujours avant de transmettre la connexion. Sinon, le Gestionnaire de pilotes continue de transmettre la connexion morte à l’application chaque fois qu’une défaillance réseau temporaire se produit. Un nouvel attribut de connexion a été défini dans ODBC 3*.x* : SQL_ATTR_CONNECTION_DEAD. Il s’agit d’un attribut de connexion en lecture seule qui retourne SQL_CD_TRUE ou SQL_CD_FALSE. La valeur SQL_CD_TRUE signifie que la connexion a été perdue, tandis que la valeur SQL_CD_FALSE signifie que la connexion est toujours active. (Les pilotes conformes aux versions antérieures d’ODBC peuvent également prendre en charge cet attribut.)

Un pilote doit implémenter cette option efficacement ou affectera les performances du regroupement de connexions. Plus précisément, un appel pour obtenir cet attribut de connexion ne doit pas entraîner un aller-retour sur le serveur. Au lieu de cela, un pilote doit simplement retourner le dernier état connu de la connexion. La connexion est morte si le dernier voyage vers le serveur a échoué, et non mort si le dernier voyage a réussi.

Notes

Si une connexion a été perdue (signalée via SQL_ATTR_CONNECTION_DEAD), le Gestionnaire de pilotes ODBC détruit cette connexion en appelant SQLDisconnect dans le pilote. Les nouvelles demandes de connexion peuvent ne pas trouver de connexion utilisable dans le pool. Finalement, le Gestionnaire de pilotes peut établir une nouvelle connexion, en supposant que le pool est vide.

Pour utiliser un pool de connexions, une application effectue les étapes suivantes :

  1. Active le regroupement de connexions en appelant SQLSetEnvAttr pour définir l’attribut d’environnement SQL_ATTR_CONNECTION_POOLING sur SQL_CP_ONE_PER_DRIVER ou SQL_CP_ONE_PER_HENV. Cet appel doit être effectué avant que l’application alloue l’environnement partagé pour lequel le regroupement de connexions doit être activé. Le handle d’environnement dans l’appel à SQLSetEnvAttr doit avoir la valeur Null, ce qui rend SQL_ATTR_CONNECTION_POOLING un attribut de niveau processus. Si l’attribut est défini sur SQL_CP_ONE_PER_DRIVER, un pool de connexions unique est pris en charge pour chaque pilote. Si une application fonctionne avec de nombreux pilotes et quelques environnements, cela peut être plus efficace, car moins de comparaisons peuvent être requises. Si la valeur est définie sur SQL_CP_ONE_PER_HENV, un pool de connexions unique est pris en charge pour chaque environnement. Si une application fonctionne avec de nombreux environnements et quelques pilotes, cela peut être plus efficace, car moins de comparaisons peuvent être requises. le regroupement Connecter ion est désactivé en définissant SQL_ATTR_CONNECTION_POOLING sur SQL_CP_OFF.

  2. Alloue un environnement en appelant SQLAllocHandle avec l’argument HandleType défini sur SQL_HANDLE_ENV. L’environnement alloué par cet appel est un environnement partagé implicite, car le regroupement de connexions a été activé. Toutefois, l’environnement à utiliser n’est pas déterminé tant que SQLAllocHandle avec un HandleType de SQL_HANDLE_DBC est appelé sur cet environnement.

  3. Alloue une connexion en appelant SQLAllocHandle avec InputHandle défini sur SQL_HANDLE_DBC, et le handle d’environnement défini sur le handle d’environnement alloué pour le regroupement de connexions. Le Gestionnaire de pilotes tente de trouver un environnement existant qui correspond aux attributs d’environnement définis par l’application. S’il n’existe aucun environnement de ce type, un environnement est créé, avec un nombre de références (géré par le Gestionnaire de pilotes) de 1. Si un environnement partagé correspondant est trouvé, l’environnement est retourné à l’application et son nombre de références est incrémenté. (La connexion réelle à utiliser n’est pas déterminée par le Gestionnaire de pilotes jusqu’à ce que SQL Connecter ou SQLDriver Connecter est appelé.)

  4. Appelle SQL Connecter ou SQLDriver Connecter pour établir la connexion. Le Gestionnaire de pilotes utilise les options de connexion dans l’appel à SQL Connecter (ou les mot clé de connexion dans l’appel à SQLDriver Connecter) et les attributs de connexion définis après l’allocation de connexion pour déterminer la connexion dans le pool à utiliser.

    Remarque

    La façon dont une connexion demandée est mise en correspondance avec une connexion mise en pool est déterminée par l’attribut d’environnement SQL_ATTR_CP_MATCH. Pour plus d’informations, consultez SQLSetEnvAttr.

    Les applications ODBC utilisant le regroupement de connexions doivent appeler CoInitializeEx pendant l’initialisation de l’application et CoUninitialize lorsque l’application se ferme.

  5. Appelle SQLDisconnect quand vous avez terminé avec la connexion. La connexion est retournée au pool de connexions et devient disponible pour la réutilisation.

Pour une discussion approfondie, consultez Regroupement dans les composants Microsoft Data Access.

Considérations relatives au regroupement d’Connecter ion

L’exécution de l’une des actions suivantes à l’aide d’une commande SQL (plutôt que via l’API ODBC) peut affecter l’état de la connexion et provoquer des problèmes inattendus lorsque le regroupement de connexions est actif :

  • Ouverture d’une connexion et modification de la base de données par défaut.

  • Utilisation de l’instruction SET pour modifier toutes les options configurables (y compris SET ROWCOUNT, ANSI_NULL, IMPLICIT_TRANSACTIONS, SHOWPLAN, STATISTICS, TEXTSIZE et DATEFORMAT).

  • Création de tables temporaires et de procédures stockées.

Si l’une de ces actions est effectuée en dehors de l’API ODBC, la personne suivante qui utilise la connexion hérite automatiquement des paramètres, tables ou procédures précédents.

Remarque

Ne vous attendez pas à ce que certains paramètres soient présents dans l’état de connexion. Vous devez toujours définir l’état de connexion dans votre application et vous assurer que l’application supprime tous les paramètres de regroupement de connexions inutilisés.

Regroupement de connexions prenant en charge les pilotes

À compter de Windows 8, un pilote ODBC peut utiliser des connexions dans le pool plus efficacement. Pour plus d’informations, consultez Regroupement de Connecter ion prenant en charge les pilotes.

Voir aussi

Connexion à une source de données ou à un pilote
Développement d’un pilote ODBC
Regroupement dans les composants Microsoft Data Access