Могу ли я указать в MSSQL (TSQL) контекстную переменную, которая находится в строке подключения, но не влияет на пул?

Question

Чтобы объяснить необходимость далее, рассмотрим следующий сценарий:

В устаревшей системе, которая в значительной степени опирается на TRIGGERS, нам нужно предоставить какой-то токен (назовем его «SessionID») для вставки в некоторые таблицы журнала безопасности. Этот токен создается в C # на сервере приложений и передается в все команды SQL.

ПЛОХО, ЭТО ТРЕБОВАНИЕ К ТРИГГЕРАМ НЕИЗМЕННО

Итак, поскольку у меня есть доступ для изменения строки подключения, я могу (и успешно доказал, что могу) использовать токен «Имя приложения» для предоставления этой информации.

string connectionString = string.Format("SERVER=sql.example.com; "
    + "DATABASE=someDB; User ID=xyz; Password=123; Application Name={0}", sID);

Так как это работает, в чем проблема?

Проблема очень проста ... вышесказанное работает, но поскольку у нас тысячи пользователей ... наш пул соединений уничтожен (поскольку пулы соединений создаются на основе строки соединения ... в основном, мне нужны пул соединений должен основываться на всем , за исключением свойства Application Name).

Итак, вы знаете, как я могу:

1. Установите свойство в строке подключения, которое НЕ будет включено в пул.
2. Установите контекстное свойство для этого соединения другим способом, который не сильно сказывается на производительности.

Как примечание ... Я мог бы открыть соединение сразу и создать временную таблицу с одним значением:

SELECT 12345 AS SessionID INTO #context

Но это кажется невероятно излишним!

Answer 1

Вы должны выполнить это, а не полагаться на строку подключения, а вместо временной таблицы SET CONTEXT_INFO / CONTEXT_INFO() можно использовать для привязки некоторых произвольных данных к текущему сеансу / соединению (и доступен в триггерах).

Если для сервера приемлемо создание переменной из некоторой комбинации пользователя / времени и т. Д., Вы можете назначить CONTEXT_INFO автоматически из триггера входа в систему , и в этом случае вам не нужно будет менять Механика соединения вообще.

Answer 2

Насколько я понимаю, отдельные пулы соединений создаются с использованием строки подключения в качестве ключа, поэтому любое контекстное изменение строки подключения неизбежно повлияет на пул

Я уже заметил свойство WorkstationId в классе SqlConnection -это может быть техника для введения некоторой контекстуализации?

            SqlConnection cn = new SqlConnection("CONNECTION_STRING");
            string identifier = cn.WorkstationId;

Answer 3

ОК, так что после большого тестирования я нашел решение.

1. Отключите пул соединений.
2. Используйте свойство «Идентификатор рабочей станции».

После некоторого бенчмаркинга я смог увидеть, что пул соединений в 50 раз быстрее, чем без использования пула ... но ... без использования пула по-прежнему требуется всего 0,005 секунды на соединение.

Я готов жить с наносекундной потерей производительности, чтобы получить необходимую нам логи безопасности.

Да, в качестве побочной точки - пул соединений имеет ОСНОВНЫЕ ограничения производительности, если все соединения выполняютсяиспользуется в данный момент, поскольку 101-й человек в очереди должен будет ждать ... так что в SOME экземплярах ... пул соединений в 1000 раз медленнее, чем без использования пула!

Answer 4

К сожалению, все в строке подключения будет принято для пула (я думаю, что они будут использовать GetHashCode (), чтобы проверить, находится ли строка в пуле).