SQL Server: пул соединений ODBC / API C - PullRequest
Новая
       23

SQL Server: пул соединений ODBC / API C

1 голос
/ 06 мая 2010

Я хочу уточнить, как сделать пул соединений с SQL Server из C, используя ODBC . Я знаю, что этот вопрос, как .... оооочень 1998, но ... я никогда не делал это в C, так что ... вот так:

Сначала я думаю, что мне нужно установить атрибут для включения пула: 

rc = SQLSetEnvAttr( NULL,  // make process level cursor pooling
                    SQL_ATTR_CONNECTION_POOLING,
                    (SQLPOINTER)SQL_CP_ONE_PER_DRIVER,
                    SQL_IS_INTEGER);

Затем выделите HENV и установите его для ODBC3.0: 

rc = SQLAllocHandle(SQL_HANDLE_ENV, NULL, &henv1);
rc = SQLSetEnvAttr(henv1, SQL_ATTR_ODBC_VERSION, (void *)SQL_OV_ODBC3, 0);

Вопросы

  1. Правильно ли, что я могу использовать HENV, выделенный выше, в нескольких параллельных потоках в рамках одного процесса, когда я вызываю SQLAllocHandle для выделения соединений БД (HDBC)?

  2. Когда я хочу использовать соединение из пула, верно ли, что типичная последовательность:

    1. SQLAllocHandle для получения дескриптора соединения (HDBC)
    2. SQLDriverConnect / [SQLConnect для подключения к этому дескриптору
    3. SQLExecute / SQLExecDirect + серия SQLFetch, чтобы использовать соединение
    4. SQLDisconnect
    5. SQLFreeConnect

  3. Есть ли значительное преимущество в задержке, если я сохраню выделенный дескриптор HDBC и повторно использую его для нескольких вызовов SQLDriverConnect + SQLDisconnect? Другими словами, я бы пропустил шаги 2.1 и 2.5 для каждого использования соединения. Или шаги 2.1 и 2.5 в основном просто malloc / free? (в этом случае, я не думаю, что мне все равно).

В этом конкретном сценарии приложение C, вероятно, будет единственным приложением, обращающимся к SQL Server из этого окна. Но он будет работать в среде IIS, и это означает, что он будет потенциально многопроцессным, а каждый процесс будет многопоточным.

Я буду получать и использовать это соединение в рамках HTTP-запроса, поэтому я хочу, чтобы оно было максимально быстрым, эффективным и масштабируемым.

...