Vývoj Connection-Pool povědomí o ovladači ODBC

Toto téma popisuje podrobnosti o vývoji ovladače ODBC, který obsahuje informace o tom, jak má ovladač poskytovat služby sdružování připojení.

Povolení sdružování připojení Driver-Aware

Ovladač musí implementovat následující funkce rozhraní ODBC Service Provider Interface (SPI):

  • SQLSetConnectAttrForDbcInfo

  • SQLSetConnectInfo

  • SQLSetDriverConnectInfo

  • SQLGetPoolID

  • SQLRateConnection

  • SQLPoolConnect

  • SQLCleanupConnectionPoolID

Další informace najdete v referenčních informacích k rozhraní ODBC Service Provider Interface (SPI ).

Ovladač musí také implementovat následující existující funkce, aby bylo možné povolit sdružování s podporou ovladačů:

Funkce Přidání funkcí
SQLAllocHandle

SQLFreeHandle

Sqlgetdiagfield

SQLGetDiagRec
Podporovat nový typ popisovače: SQL_HANDLE_DBC_INFO_TOKEN (viz popis níže).
SQLSetConnectAttr Podpora nového pouze nastavitelného atributu připojení SQL_ATTR_DBC_INFO_TOKEN pro resetování připojení (viz popis níže).

Poznámka:

Zastaralé funkce, jako je SQLError a SQLSetConnectOption , nejsou podporovány pro sdružování připojení podporujících ovladače.

ID poolu

ID fondu je ID specifický pro ovladač a délku ukazatele, představující konkrétní skupinu připojení, které lze používat zaměnitelně. Vzhledem k sadě informací o připojení by měl být ovladač schopen rychle odvodit odpovídající pool ID.

ID fondu by například mělo kódovat název serveru a informace o přihlašovacích údaji. Název databáze však není potřeba, protože ovladač může znovu použít připojení a pak databázi změnit za kratší dobu než vytvořit nové připojení.

Ovladač by měl definovat sadu klíčových atributů, které budou obsahovat ID fondu. Hodnota těchto klíčových atributů může pocházet z atributů připojení, připojovacího řetězce a DSN. Pokud v těchto zdrojích dojde ke konfliktům, měly by se pro zpětnou kompatibilitu použít stávající zásady řešení specifické pro ovladače.

Správce ovladačů použije různé pooly pro různá ID poolu. Všechna připojení ve stejném fondu jsou opakovaně použitelná. Správce ovladačů nikdy nebude opakovaně používat připojení s jiným pool ID.

Ovladače by proto měly přiřadit jedinečné ID fondu pro každou skupinu připojení se stejnou hodnotou v definovaných klíčových atributech. Pokud ovladač používá stejné ID fondu pro dvě připojení s různými hodnotami ve svých klíčových atributech, Správce ovladačů je stále vloží do stejného fondu (Správce ovladačů neví nic o atributech klíčů specifických pro ovladač). To znamená, že ovladač bude muset nahlásit správci ovladačů, že připojení s jinou sadou klíčových atributů není opakovaně použitelné uvnitř funkce SQLRateConnection. To může snížit výkon a nedoporučuje se to.

Správce ovladačů nebude opakovaně používat připojení přidělené z jiného prostředí ovladače, i když všechny informace o připojení odpovídají. Správce ovladačů použije pro jiné prostředí jiný fond, a to i v případě, že připojení mají stejné ID fondu. ID fondu je proto lokální vůči prostředí jeho ovladače.

Funkce pro získání ID fondu z ovladače je SQLGetPoolID Function.

Hodnocení připojení

V porovnání s navazováním nového připojení můžete dosáhnout lepšího výkonu resetováním některých informací o připojení (například DATABASE) ve fondu připojení. Proto možná nebudete chtít, aby název databáze byl ve vaší sadě klíčových atributů. Jinak můžete mít samostatný fond pro každou databázi, což nemusí být vhodné v aplikacích střední vrstvy, kde zákazníci používají různé připojovací řetězce.

Kdykoli znovu použijete připojení, které má neshodu atributů, měli byste resetovat neodpovídající atributy na základě nového požadavku aplikace, aby vrácené připojení bylo stejné jako u požadavku aplikace (viz diskuze o atributu SQL_ATTR_DBC_INFO_TOKEN ve funkci SQLSetConnectAttr). Resetování těchto atributů však může snížit výkon. Například resetování databáze vyžaduje síťové volání serveru. Proto znovu použijte připojení, které je dokonale spárované, pokud je k dispozici.

Funkce hodnocení v ovladači může vyhodnotit stávající připojení s novou žádostí o připojení. Například funkce hodnocení řidiče může určit:

  • Pokud se stávající připojení přesně shoduje s požadavkem.

  • Pokud dojde pouze k nevýznamným neshodám, například vypršení časového limitu připojení, které nevyžadují komunikaci se serverem k resetování.

  • Pokud existují některé neodpovídající atributy, které vyžadují komunikaci se serverem k resetování, ale přesto by to vedlo k lepšímu výkonu než vytvoření nového připojení.

  • Pokud došlo k neshodě u atributu, jehož resetování je velmi časově náročné (vývojář ovladače může zvážit přidání tohoto atributu do sady klíčových atributů, která se používá k vygenerování ID poolu).

Skóre mezi 0 a 100 je možné, kde 0 znamená neopakovat a 100 znamená dokonale shodné. SQLRateConnection je funkce pro hodnocení připojení.

Nový popisovač ODBC – SQL_HANDLE_DBC_INFO_TOKEN

Pro podporu sdružování připojení s ohledem na ovladače potřebuje ovladač informace o připojení ke stanovení ID fondu. Ovladač také potřebuje informace o připojení k porovnání nových požadavků na připojení s připojeními ve fondu. Kdykoli není možné znovu použít žádné připojení ve fondu, musí ovladač navázat nové připojení, a proto vyžaduje informace o připojení.

Vzhledem k tomu, že informace o připojení můžou pocházet z více zdrojů (připojovací řetězec, atributy připojení a DSN), ovladač může potřebovat analyzovat připojovací řetězec a vyřešit konflikt mezi těmito zdroji v každém z výše uvedených volání funkce.

Proto je zaveden nový popisovač ODBC: SQL_HANDLE_DBC_INFO_TOKEN. U SQL_HANDLE_DBC_INFO_TOKEN nemusí ovladač analyzovat připojovací řetězec a řešit konflikty v informacích o připojení více než jednou. Vzhledem k tomu, že se jedná o datovou strukturu specifickou pro ovladač, může ovladač ukládat data, jako jsou informace o připojení nebo ID fondu.

Tento popisovač se používá pouze jako rozhraní mezi Správcem ovladačů a ovladačem. Aplikace nemůže tento popisovač přidělit přímo.

Nadřazený popisovač tohoto popisovače je typu SQL_HANDLE_ENV, což znamená, že ovladač může během vyhodnocování informací o připojení získat informace o prostředí z popisovače HENV.

Pokaždé, když obdrží novou žádost o připojení, správce ovladačů přidělí popisovač typu SQL_HANDLE_DBC_INFO_TOKEN pro ukládání informací o připojení, jakmile potvrdí, že ovladač podporuje povědomí o fondu připojení. Po dokončení použití popisovače (ale před vrácením některých návratových kódů jiných než SQL_STILL_EXECUTING z SQLDriverConnect nebo SQLConnect), Správce ovladačů uvolní popisovač. Proto je popisovač vytvořen po volání SQLAllocHandle a zničen po volání SQLFreeHandle. Správce ovladačů zaručuje, že popisovač bude uvolněn před uvolněním přidruženého HENV (když SQLDriverConnect nebo SQLConnect vrátí chybu).

Ovladač by měl upravit následující funkce tak, aby přijímal nový typ popisovače SQL_HANDLE_DBC_INFO_TOKEN:

  1. SQLAllocHandle

  2. SQLFreeHandle

  3. Sqlgetdiagfield

  4. SQLGetDiagRec

Správce ovladačů zaručuje, že více vláken nebude současně používat popisovač SQL_HANDLE_DBC_INFO_TOKEN. Proto synchronizační model tohoto popisovače může být velmi jednoduchý uvnitř ovladače. Správce ovladačů před alokací a uvolněním SQL_HANDLE_DBC_INFO_TOKEN nezamkne prostředí.

Správce ovladačů SQLAllocHandle a SQLFreeHandle tento nový typ popisovače nepřijme.

SQL_HANDLE_DBC_INFO_TOKEN může obsahovat důvěrné informace, jako jsou přihlašovací údaje. Ovladač by proto měl bezpečně vymazat paměťový buffer (pomocí SecureZeroMemory), který obsahuje citlivé informace, před uvolněním tohoto popisovače pomocí SQLFreeHandle. Při každém zavření obslužného objektu prostředí aplikace se zavřou všechny související fondy připojení.

Algoritmus hodnocení fondu připojení Správce ovladačů

Tato část popisuje algoritmus hodnocení pro sdružování připojení Správce ovladačů. Vývojáři ovladačů mohou implementovat stejný algoritmus pro zpětnou kompatibilitu. Tento algoritmus nemusí být nejlepší. Tento algoritmus byste měli upřesnit na základě vaší implementace (jinak neexistuje důvod k implementaci této funkce).

Správce ovladačů vrátí celočíselné hodnocení od 0 do 100 pro každé připojení z fondu. 0 znamená, že připojení nelze znovu použít a 100 značí perfektní shodu. Předpokládejme, že požadavek na připojení má název hRequest a existující připojení z fondu má název hCandidate. Pokud není splněna některá z následujících podmínek, nelze sdílené připojení hCandidate znovu použít pro hRequest (Správce ovladačů přiřadí hodnocení 0).

  • hCandidate a hRequest oba pocházejí z rozhraní UNICODE API (například SQLDriverConnectW) nebo rozhraní ANSI API (například SQLDriverConnectA). (Ovladače UNICODE můžou chovat jinak vzhledem k rozhraní ANSI API a rozhraní UNICODE API (viz atribut připojení SQL_ATTR_ANSI_APP).)

  • hCandidate a hRequest jsou vytvořeny stejnou funkcí; SQLDriverConnect nebo SQLConnect.

  • Připojovací řetězec použitý k otevření hCandidate by měl být stejný jako hRequest, když se použije SQLDriverConnect.

  • Název serveru (NEBO DSN), uživatelské jméno a heslo použité k otevření hCandidate by měly být stejné jako při použití příkazu hRequest.

  • Identifikátor zabezpečení (SID) aktuálního vlákna by měl být stejný jako identifikátor SID použitý k otevření hCandidate.

  • Pro ovladač, který je nákladný pro zařazení a vyřazení (viz diskuze o SQL_DTC_TRANSITION_COST v SQLConnect), opětovné použití hRequest nesmí vyžadovat dodatečné zařazení nebo vyřazení.

Následující tabulka ukazuje přiřazení skóre pro různé scénáře.

Porovnání atributů připojení mezi sdruženým spojením a požadavkem Bez zařazení / vyřazení Vyžadování dodatečného přihlášení / odhlášení
Katalog (SQL_ATTR_CURRENT_CATALOG) se liší 60 50
Některé atributy připojení se liší, ale katalog je stejný. 90 70
Všechny atributy připojení jsou dokonale spárované. 100 80

Sekvenční diagram

Tento sekvenční diagram znázorňuje základní mechanismus sdružování popsaný v tomto tématu. Zobrazuje pouze použití funkce SQLDriverConnect , ale případ SQLConnect je podobný.

Sekvenční diagram

Diagram stavu

Tento stavový diagram znázorňuje objekt tokenu informací o připojení, který je popsaný v tomto tématu. Diagram zobrazuje pouze sqlDriverConnect , ale případ SQLConnect je podobný. Vzhledem k tomu, že správce ovladačů může kdykoli potřebovat zpracovat chyby, správce ovladačů může volat SQLFreeHandle pro libovolný stav.

Stavový diagram odbc_state_diagram

Viz také

sdružování připojeníDriver-Aware
Referenční informace k rozhraní ODBC Service Provider Interface (SPI)