Entwickeln von Verbindungspool-Unterstützung in einem ODBC-Treiber
In diesem Thema werden die Details der Entwicklung eines ODBC-Treibers erläutert, der Informationen dazu enthält, wie der Treiber Verbindungspooldienste bereitstellen soll.
Aktivieren von treiberfähigen Verbinden ion-Pooling
Ein Treiber muss die folgenden SPI-Funktionen (ODBC Service Provider Interface) implementieren:
SQLSet Verbinden AttrForDbcInfo
SQLSet Verbinden Info
SQLSetDriver Verbinden Info
SQLGetPoolID
SQLRate Verbinden ion
SQLPool Verbinden
SQLCleanup Verbinden ionPoolID
Weitere Informationen finden Sie in der ODBC Service Provider Interface (SPI)-Referenz .
Ein Treiber muss auch die folgenden vorhandenen Funktionen implementieren, damit die treiberfähige Poolerstellung aktiviert werden kann:
| Funktion | Hinzugefügte Funktionalität |
|---|---|
| SQLAllocHandle SQLFreeHandle SQLGetDiagField Sqlgetdiagrec |
Unterstützen Sie den neuen Handletyp: SQL_HANDLE_DBC_INFO_TOKEN (siehe beschreibung unten). |
| SQLSetConnectAttr | Unterstützung des neuen set-only-Verbindungsattributes: SQL_ATTR_DBC_INFO_TOKEN zum Zurücksetzen der Verbindung (siehe beschreibung unten). |
Hinweis
Veraltete Funktionen wie SQLError und SQLSet Verbinden Option werden für treiberfähige Verbindungspooling nicht unterstützt.
Die Pool-ID
Die Pool-ID ist eine treiberspezifische Zeiger-ID, die eine bestimmte Gruppe von Verbindungen darstellt, die austauschbar verwendet werden können. Angesichts einer Reihe von Verbindungsinformationen sollte ein Treiber schnell die entsprechende Pool-ID ableiten können.
Beispielsweise sollte die Pool-ID den Servernamen und anmeldeinformationen codieren. Der Datenbankname ist jedoch nicht erforderlich, da ein Treiber möglicherweise eine Verbindung wiederverwenden und dann die Datenbank in kürzerer Zeit ändern kann als eine neue Verbindung.
Ein Treiber sollte eine Reihe von Schlüsselattributen definieren, die die Pool-ID umfassen. Der Wert dieser Schlüsselattribute kann aus Verbindungsattributen, Verbindungszeichenfolge und DSN stammen. Falls in diesen Quellen Konflikte auftreten, sollte die vorhandene treiberspezifische Lösungsrichtlinie aus Gründen der Abwärtskompatibilität verwendet werden.
Der Treiber-Manager verwendet einen anderen Pool für verschiedene Pool-IDs. Alle Verbindungen im selben Pool sind wiederverwendbar. Der Treiber-Manager verwendet niemals eine Verbindung mit einer anderen Pool-ID.
Daher sollten Treiber eine eindeutige Pool-ID für jede Gruppe von Verbindungen mit demselben Wert in ihren definierten Schlüsselattributen zuweisen. Wenn ein Treiber die gleiche Pool-ID für zwei Verbindungen mit unterschiedlichen Werten in seinen Schlüsselattributen verwendet, fügt der Treiber-Manager sie weiterhin in denselben Pool ein (der Treiber-Manager kennt nichts über die treiberspezifischen Schlüsselattribute). Dies bedeutet, dass der Treiber dem Treiber-Manager melden muss, dass eine Verbindung mit einem anderen Satz von Schlüsselattributen nicht innerhalb von SQLRate Verbinden ion Function wiederverwendbar ist. Dies kann die Leistung verringern und dies wird nicht empfohlen.
Der Treiber-Manager verwendet keine Verbindung, die einer anderen Treiberumgebung zugeordnet ist, auch wenn alle Verbindungsinformationen übereinstimmen. Der Treiber-Manager verwendet einen anderen Pool für unterschiedliche Umgebungen, auch wenn Verbindungen dieselbe Pool-ID aufweisen. Daher ist die Pool-ID lokal für die Treiberumgebung.
Die Funktion zum Abrufen der Pool-ID vom Treiber ist die SQLGetPoolID-Funktion.
Die Verbinden ion-Bewertung
Im Vergleich zum Herstellen einer neuen Verbindung können Sie eine bessere Leistung erzielen, indem Sie einige Verbindungsinformationen (z. B. DATENBANK) in einer poolierten Verbindung zurücksetzen. Daher möchten Sie möglicherweise nicht, dass sich der Datenbankname in Ihrer Gruppe von Schlüsselattributen befindet. Andernfalls können Sie einen separaten Pool für jede Datenbank haben, was in Anwendungen auf mittlerer Ebene möglicherweise nicht gut ist, bei denen Kunden verschiedene Verbindungszeichenfolge verwenden.
Wenn Sie eine Verbindung wiederverwenden, bei der ein Attributkonflikt besteht, sollten Sie die nicht übereinstimmenden Attribute basierend auf der neuen Anwendungsanforderung zurücksetzen, sodass die zurückgegebene Verbindung mit der Anwendungsanforderung identisch ist (siehe Erläuterung des Attributs SQL_ATTR_DBC_INFO_TOKEN in SQLSet Verbinden Attr Function). Durch das Zurücksetzen dieser Attribute kann die Leistung jedoch verringert werden. Zum Beispiel erfordert das Zurücksetzen einer Datenbank einen Netzwerkaufruf an den Server. Verwenden Sie daher eine Verbindung, die perfekt übereinstimmt, wenn eine verfügbar ist.
Eine Bewertungsfunktion im Treiber kann eine vorhandene Verbindung mit einer neuen Verbindungsanforderung auswerten. Die Bewertungsfunktion des Treibers kann z. B. folgendes bestimmen:
Wenn die vorhandene Verbindung perfekt mit der Anforderung übereinstimmt.
Wenn es nur einige unbedeutende Übereinstimmungen gibt, z. B. Verbindungstimeout, die keine Kommunikation mit dem Server erfordern, um zurückzusetzen.
Wenn es einige nicht übereinstimmende Attribute gibt, die eine Kommunikation mit dem Server erfordern, die zurückgesetzt werden soll, aber dennoch zu einer besseren Leistung führen würde, als eine neue Verbindung herzustellen.
Wenn die übereinstimmungslos für ein Attribut aufgetreten ist, das sehr zeitaufwändig zurückgesetzt werden kann (der Entwickler des Treibers kann erwägen, dieses Attribut in den Satz der Schlüsselattribute hinzuzufügen, die zum Generieren der Pool-ID verwendet wird).
Eine Punktzahl zwischen 0 und 100 ist möglich, wobei 0 bedeutet, dass 0 nicht wiederverwendet wird und 100 perfekt aufeinander abgestimmt ist. SQLRate Verbinden ion ist die Funktion für die Bewertung einer Verbindung.
Neuer ODBC-Handle – SQL_HANDLE_DBC_INFO_TOKEN
Zur Unterstützung der treiberfähigen Verbindungspooling benötigt der Treiber Verbindungsinformationen, um die Pool-ID zu berechnen. Der Treiber benötigt außerdem Verbindungsinformationen, um neue Verbindungsanforderungen mit Verbindungen im Pool zu vergleichen. Wenn keine Verbindung im Pool wiederverwendet werden kann, muss der Treiber eine neue Verbindung herstellen, sodass Verbindungsinformationen erforderlich sind.
Da Verbindungsinformationen aus mehreren Quellen (Verbindungszeichenfolge, Verbindungsattributen und DSN) stammen können, muss der Treiber möglicherweise die Verbindungszeichenfolge analysieren und den Konflikt zwischen diesen Quellen in jedem der oben genannten Funktionsaufrufe lösen.
Daher wird ein neuer ODBC-Handle eingeführt: SQL_HANDLE_DBC_INFO_TOKEN. Bei SQL_HANDLE_DBC_INFO_TOKEN muss ein Treiber die Verbindungszeichenfolge nicht analysieren und Konflikte in Verbindungsinformationen mehrmals lösen. Da es sich um eine treiberspezifische Datenstruktur handelt, kann der Treiber Daten wie Verbindungsinformationen oder Pool-ID speichern.
Dieses Handle wird nur als Schnittstelle zwischen dem Treiber-Manager und dem Treiber verwendet. Eine Anwendung kann dieses Handle nicht direkt zuordnen.
Der übergeordnete Handle dieses Handles ist vom Typ SQL_HANDLE_ENV, d. h., der Treiber kann die Umgebungsinformationen aus dem HENV-Handle während der Verbindungsinformationsauflösung abrufen.
Wenn sie eine neue Verbindungsanforderung empfängt, weist der Treiber-Manager ein Handle vom Typ SQL_HANDLE_DBC_INFO_TOKEN zum Speichern von Verbindungsinformationen zu, nachdem bestätigt wurde, dass der Treiber das Bewusstsein für verbindungspools unterstützt. Nach Abschluss der Verwendung des Handles (vor dem Zurückgeben einiger Rückgabecodes außer SQL_STILL_EXECUTING von SQLDriver Verbinden oder SQL Verbinden) wird der Treiber-Manager das Handle freigeben. Daher wird das Handle nach dem SQLAllocHandle-Aufruf erstellt und nach dem SQLFreeHandle-Aufruf zerstört. Der Treiber-Manager garantiert, dass der Handle freigegeben wird, bevor er seinen zugeordneten HENV freigibt (wenn SQLDriver Verbinden oder SQL Verbinden einen Fehler zurückgibt).
Der Treiber sollte die folgenden Funktionen ändern, um den neuen Handletyp SQL_HANDLE_DBC_INFO_TOKEN zu akzeptieren:
Der Treiber-Manager garantiert, dass mehrere Threads nicht das gleiche SQL_HANDLE_DBC_INFO_TOKEN gleichzeitig verwenden. Daher kann das Synchronisierungsmodell dieses Handles sehr einfach innerhalb des Treibers sein. Der Treiber-Manager übernimmt vor dem Zuweisen und Freigeben von SQL_HANDLE_DBC_INFO_TOKEN keine Umgebungssperre.
Die SQLAllocHandle und SQLFreeHandle des Treiber-Managers akzeptieren diesen neuen Handletyp nicht.
SQL_HANDLE_DBC_INFO_TOKEN können vertrauliche Informationen wie Anmeldeinformationen enthalten. Daher sollte ein Treiber den Speicherpuffer (mit SecureZeroMemory) sicher löschen, der die vertraulichen Informationen enthält, bevor dieser Handle mit SQLFreeHandle freigegeben wird. Wenn das Umgebungshandle einer Anwendung geschlossen wird, werden alle zugeordneten Verbindungspools geschlossen.
Treiber-Manager Verbinden ion Pool-Bewertungsalgorithmus
In diesem Abschnitt wird der Bewertungsalgorithmus für den Treiber-Manager-Verbindungspooling erläutert. Treiberentwickler können denselben Algorithmus zur Abwärtskompatibilität implementieren. Dieser Algorithmus ist möglicherweise nicht die beste. Sie sollten diesen Algorithmus basierend auf Ihrer Implementierung verfeinern (andernfalls gibt es keinen Grund, dieses Feature zu implementieren).
Der Treiber-Manager gibt für jede Verbindung vom Pool eine integrale Bewertung von 0 bis 100 zurück. 0 bedeutet, dass die Verbindung nicht wiederverwendet werden kann und 100 eine perfekte Übereinstimmung anzeigt. Angenommen, die Verbindungsanforderung heißt hRequest, und die vorhandene Verbindung aus dem Pool wird als hCandidate benannt. Wenn eine der folgenden Bedingungen falsch ist, kann die poolierte Verbindung hCandidate nicht für hRequest wiederverwendet werden (der Treiber-Manager weist eine Bewertung von 0 zu).
hCandidate und hRequest stammen beide aus einer UNICODE-API (z. B. SQLDriver Verbinden W) oder einer ANSI-API (z. B. SQLDriver Verbinden A). (UNICODE-Treiber können sich je nach ANSI-API und UNICODE-API unterscheiden (siehe Verbindungsattribute SQL_ATTR_ANSI_APP).)
hCandidate und hRequest werden von derselben Funktion erstellt; entweder SQLDriver Verbinden oder SQL Verbinden.
Die zum Öffnen von hCandidate verwendete Verbindungszeichenfolge sollte mit hRequest identisch sein, wenn SQLDriver Verbinden verwendet wird.
Der Zum Öffnen von hCandidate verwendete ServerName (oder DSN), Benutzername und Kennwort sollten zum Öffnen von hRequest verwendet werden, wenn SQL Verbinden verwendet wird.
Die Sicherheits-ID (SID) des aktuellen Threads sollte mit der SID übereinstimmen, die zum Öffnen von hCandidate verwendet wird.
Für Treiber, der teuer ist, um eine Liste auflisten und nicht auflisten zu können (siehe Die Diskussion über SQL_DTC_TRANSITION_COST in SQL Verbinden), darf die erneute Nutzung von hRequest keine zusätzliche Einlistung oder Nichtauflistung erfordern.
Die folgende Tabelle zeigt die Bewertungszuweisung für verschiedene Szenarien.
| Vergleich von Verbindungsattributen zwischen der poolierten Verbindung und der Anforderung | Keine Enlistment/Nichteinlistung | Zusätzliche Auflistung erforderlich/ Nichtauflistung |
|---|---|---|
| Katalog (SQL_ATTR_CURRENT_CATALOG) unterscheidet sich | 60 | 50 |
| Einige Verbindungsattribute sind unterschiedlich, katalog ist jedoch identisch. | 90 | 70 |
| Alle Verbindungsattribute sind perfekt aufeinander abgestimmt. | 100 | 80 |
Sequenzdiagramm
Dieses Sequenzdiagramm zeigt den grundlegenden Poolingmechanismus, der in diesem Thema beschrieben wird. Es zeigt nur die Verwendung von SQLDriver Verbinden aber der SQL Verbinden Fall ist ähnlich.
Statusdiagramm
Dieses Zustandsdiagramm zeigt das In diesem Thema beschriebene Verbindungsinformationstokenobjekt. Das Diagramm zeigt nur SQLDriver Verbinden aber der SQL Verbinden Fall ist ähnlich. Da der Treiber-Manager jederzeit Fehler behandeln muss, kann der Treiber-Manager SQLFreeHandle für jeden Zustand aufrufen.
Weitere Informationen
Treiberfähiges Verbindungspooling
ODBC-Dienstanbieterschnittstelle (Service Provider Interface, SPI) – Referenz