Développement de la reconnaissance des pools de connexions dans un pilote ODBC

Cette rubrique décrit les détails du développement d’un pilote ODBC qui contient des informations sur la façon dont le pilote doit fournir des services de regroupement de connexions.

Activation du regroupement de Connecter ion prenant en charge le pilote

Un pilote doit implémenter les fonctions SPI (ODBC Service Provider Interface) suivantes :

• SQLSet Connecter AttrForDbcInfo

• SQLSet Connecter Info

• SQLSetDriver Connecter Info

• SQLGetPoolID

• SQLRate Connecter ion

• SQLPool Connecter

• SQLCleanup Connecter ionPoolID

Pour plus d’informations, consultez la référence SPI (ODBC Service Provider Interface).

Un pilote doit également implémenter les fonctions existantes suivantes afin que le regroupement prenant en charge le pilote puisse être activé :

ID du pool

L’ID de pool est un ID spécifique au pilote de longueur de pointeur pour représenter un groupe particulier de connexions qui peuvent être utilisées de manière interchangeable. Étant donné un ensemble d’informations de connexion, un pilote doit être en mesure de déduire rapidement l’ID de pool correspondant.

Par exemple, l’ID du pool doit encoder le nom du serveur et les informations d’identification. Toutefois, le nom de la base de données n’est pas nécessaire, car un pilote peut être en mesure de réutiliser une connexion, puis de modifier la base de données en moins de temps que d’établir une nouvelle connexion.

Un pilote doit définir un ensemble d’attributs de clé, qui comprend l’ID du pool. La valeur de ces attributs clés peut provenir d’attributs de connexion, de chaîne de connexion et de DSN. En cas de conflit dans ces sources, la stratégie de résolution spécifique au pilote existante doit être utilisée pour la compatibilité descendante.

Le Gestionnaire de pilotes utilisera un pool différent pour différents ID de pool. Toutes les connexions dans le même pool sont réutilisables. Le Gestionnaire de pilotes ne réutilisera jamais de connexion avec un ID de pool différent.

Par conséquent, les pilotes doivent affecter un ID de pool unique pour chaque groupe de connexions avec la même valeur dans leurs attributs de clé définis. Si un pilote utilise le même ID de pool pour deux connexions avec des valeurs différentes dans leurs attributs clés, le Gestionnaire de pilotes les place toujours dans le même pool (le Gestionnaire de pilotes ne connaît rien sur les attributs de clé spécifiques au pilote). Cela signifie que le pilote doit signaler au Gestionnaire de pilotes qu’une connexion avec un autre ensemble d’attributs de clé n’est pas réutilisable dans SQLRate Connecter ion Function. Cela peut diminuer les performances et cela n’est pas recommandé.

Le Gestionnaire de pilotes ne réutilisera pas une connexion allouée à partir d’un autre environnement de pilote, même si toutes les informations de connexion correspondent. Le Gestionnaire de pilotes utilise un pool différent pour un environnement différent, même lorsque les connexions ont le même ID de pool. Par conséquent, l’ID du pool est local dans son environnement de pilote.

La fonction permettant d’obtenir l’ID du pool à partir du pilote est la fonction SQLGetPoolID.

Évaluation de la Connecter ion

Par rapport à l’établissement d’une nouvelle connexion, vous pouvez obtenir de meilleures performances en réinitialisant certaines informations de connexion (telles que DATABASE) dans une connexion mise en pool. Par conséquent, vous ne souhaiterez peut-être pas que le nom de la base de données soit dans votre ensemble d’attributs de clé. Sinon, vous pouvez avoir un pool distinct pour chaque base de données, qui peut ne pas être bon dans les applications de niveau intermédiaire, où les clients utilisent différents chaîne de connexion.

Chaque fois que vous réutilisez une connexion ayant une incompatibilité d’attribut, vous devez réinitialiser les attributs incompatibles en fonction de la nouvelle demande d’application, afin que la connexion retournée soit identique à la demande d’application (voir la discussion de l’attribut SQL_ATTR_DBC_INFO_TOKEN dans SQLSet Connecter Attr Function). Toutefois, la réinitialisation de ces attributs peut diminuer les performances. Par exemple, la réinitialisation d’une base de données nécessite un appel réseau au serveur. Par conséquent, réutilisez une connexion parfaitement adaptée, si elle est disponible.

Une fonction d’évaluation dans le pilote peut évaluer une connexion existante avec une nouvelle demande de connexion. Par exemple, la fonction d’évaluation du pilote peut déterminer :

• Si la connexion existante est parfaitement adaptée à la demande.

• S’il n’existe que des incompatibilités non significatives, telles que le délai d’expiration de la connexion, qui ne nécessitent pas de communication avec le serveur pour la réinitialisation.

• S’il existe des attributs incompatibles qui nécessitent une communication avec le serveur à réinitialiser, mais cela entraînerait toujours de meilleures performances que l’établissement d’une nouvelle connexion.

• Si l’incompatibilité s’est produite pour un attribut qui est très long à réinitialiser (le développeur du pilote peut envisager d’ajouter cet attribut dans l’ensemble d’attributs clés, qui est utilisé pour générer l’ID du pool).

Un score compris entre 0 et 100 est possible, où 0 signifie ne pas réutiliser et 100 signifie parfaitement mis en correspondance. SQLRate Connecter ion est la fonction d’évaluation d’une connexion.

Nouveau handle ODBC - SQL_HANDLE_DBC_INFO_TOKEN

Pour prendre en charge le regroupement de connexions prenant en charge le pilote, le pilote a besoin d’informations de connexion pour calculer l’ID du pool. Le pilote a également besoin d’informations de connexion pour comparer les nouvelles demandes de connexion avec les connexions dans le pool. Chaque fois qu’aucune connexion dans le pool ne peut être réutilisée, le pilote doit établir une nouvelle connexion, ce qui nécessite des informations de connexion.

Étant donné que les informations de connexion peuvent provenir de plusieurs sources (chaîne de connexion, attributs de connexion et DSN), le pilote peut avoir besoin d’analyser la chaîne de connexion et de résoudre le conflit entre ces sources dans chacun des appels de fonction ci-dessus.

Par conséquent, un nouveau handle ODBC est introduit : SQL_HANDLE_DBC_INFO_TOKEN. Avec SQL_HANDLE_DBC_INFO_TOKEN, un pilote n’a pas besoin d’analyser la chaîne de connexion et de résoudre les conflits dans les informations de connexion plusieurs fois. Étant donné qu’il s’agit d’une structure de données spécifique au pilote, le pilote peut stocker des données telles que des informations de connexion ou un ID de pool.

Ce handle est utilisé uniquement comme interface entre le Gestionnaire de pilotes et le pilote. Une application ne peut pas allouer ce handle directement.

Le handle parent de ce handle est de type SQL_HANDLE_ENV, ce qui signifie que le pilote peut obtenir les informations d’environnement du handle HENV pendant la résolution des informations de connexion.

Chaque fois qu’il reçoit une nouvelle demande de connexion, le Gestionnaire de pilotes alloue un handle de type SQL_HANDLE_DBC_INFO_TOKEN pour stocker les informations de connexion, une fois qu’il confirme que le pilote prend en charge la prise en charge de la sensibilisation au pool de connexions. Lorsque vous avez terminé d’utiliser le handle (mais avant de retourner des codes de retour autres que SQL_STILL_EXECUTING à partir de SQLDriver Connecter ou SQL Connecter), le Gestionnaire de pilotes libère le handle. Par conséquent, le handle est créé après l’appel SQLAllocHandle et détruit après l’appel SQLFreeHandle. Le Gestionnaire de pilotes garantit que le handle sera libéré avant de libérer son HENV associé (lorsque SQLDriver Connecter ou SQL Connecter retourne une erreur).

Le pilote doit modifier les fonctions suivantes pour accepter le nouveau type de handle SQL_HANDLE_DBC_INFO_TOKEN :

1. SQLAllocHandle

2. SQLFreeHandle

3. SQLGetDiagField

4. SQLGetDiagRec

Le Gestionnaire de pilotes garantit que plusieurs threads n’utiliseront pas simultanément le même handle SQL_HANDLE_DBC_INFO_TOKEN. Par conséquent, le modèle de synchronisation de ce handle peut être très simple à l’intérieur du pilote. Le Gestionnaire de pilotes ne prend pas de verrou d’environnement avant d’allouer et de libérer des SQL_HANDLE_DBC_INFO_TOKEN.

SQLAllocHandle et SQLFreeHandle du Gestionnaire de pilotes n’acceptent pas ce nouveau type de handle.

SQL_HANDLE_DBC_INFO_TOKEN peut contenir des informations confidentielles telles que des informations d’identification. Par conséquent, un pilote doit effacer en toute sécurité la mémoire tampon (à l’aide de SecureZeroMemory) qui contient les informations sensibles avant de libérer ce handle avec SQLFreeHandle. Chaque fois que le handle d’environnement d’une application est fermé, tous les pools de connexions associés sont fermés.

Algorithme d’évaluation du pool de pilotes Connecter ion

Cette section décrit l’algorithme d’évaluation pour le regroupement de connexions Driver Manager. Les développeurs de pilotes peuvent implémenter le même algorithme pour la compatibilité descendante. Cet algorithme n’est peut-être pas le meilleur. Vous devez affiner cet algorithme en fonction de votre implémentation (sinon, il n’existe aucune raison d’implémenter cette fonctionnalité).

Le Gestionnaire de pilotes retourne une évaluation intégrale comprise entre 0 et 100 pour chaque connexion du pool. 0 signifie que la connexion ne peut pas être réutilisée et 100 indique une correspondance parfaite. Supposons que la demande de connexion est nommée hRequest et que la connexion existante à partir du pool est nommée en tant que hCandidate. Si l’une des conditions suivantes est false, la connexion mise en pool hCandidate ne peut pas être réutilisée pour hRequest (le Gestionnaire de pilotes attribue une évaluation de 0).

• hCandidate et hRequest proviennent tous deux de l’API UNICODE (par exemple, SQLDriver Connecter W) ou de l’API ANSI (par exemple, SQLDriver Connecter A). (Les pilotes UNICODE peuvent comportement différents en fonction de l’API ANSI et de l’API UNICODE (voir l’attribut de connexion SQL_ATTR_ANSI_APP).)

• hCandidate et hRequest sont créés par la même fonction ; SQLDriver Connecter ou SQL Connecter.

• Le chaîne de connexion utilisé pour ouvrir hCandidate doit être identique à hRequest, lorsque SQLDriver Connecter est utilisé.

• Le nom d’utilisateur (ou DSN), le nom d’utilisateur et le mot de passe utilisés pour ouvrir hCandidate doivent être les mêmes utilisés pour ouvrir hRequest lorsque SQL Connecter est utilisé.

• L’identificateur de sécurité (SID) du thread actuel doit être identique au SID utilisé pour ouvrir hCandidate.

• Pour les pilotes coûteux à inscrire et à désinscrire (voir la discussion de SQL_DTC_TRANSITION_COST dans SQL Connecter), la réutilisation de hRequest ne doit pas nécessiter d’inscription supplémentaire ou de non-inscription.

Le tableau suivant montre l’attribution de score pour différents scénarios.

Diagramme de séquence

Ce diagramme de séquence montre le mécanisme de regroupement de base décrit dans cette rubrique. Il affiche uniquement l’utilisation de SQLDriver Connecter mais le cas SQL Connecter est similaire.

Diagramme d’état

Ce diagramme d’état montre l’objet de jeton d’informations de connexion, décrit dans cette rubrique. Le diagramme montre uniquement SQLDriver Connecter mais le cas SQL Connecter est similaire. Étant donné que le Gestionnaire de pilotes peut avoir besoin de gérer des erreurs à tout moment, le Gestionnaire de pilotes peut appeler SQLFreeHandle pour n’importe quel état.

Voir aussi

Regroupement de connexions prenant en charge les pilotes
Informations de référence sur l’interface SPI ODBC