Verificando o lado do servidor do pool de conexões com CONTEXT_INFO ativado

Primeiro, CONTEXT_INFOé uma propriedade da sessão, não da conexão. Ele é redefinido por sp_reset_connection quando a mesma sessão é reutilizada e o primeiro lote é executado. Parece que nãoCONTEXT_INFO foi redefinido no SQL Server 2000 e possivelmente em versões anteriores, mas a partir do SQL Server 2005 é definitivamente redefinido para .NULL

Parte da confusão aqui é que a pergunta é específica para "Microsoft Dynamics AX", já que a programação geral do .NET não teria a chave de registro indicada naquele artigo do blog. Além disso, as informações que o Microsoft Dynamics está armazenando CONTEXT_INFOsão os detalhes da sessão do aplicativo, que não têm nada a ver com os SPIDs do SQL Server e não podem ser usados ​​para inferir que o pool de conexões está ocorrendo, pois a sessão do aplicativo abrangerá naturalmente várias conexões, bem como os SPIDs .

O mecanismo que está sendo usado para definir CONTEXT_INFOpraticamente deve ser uma consulta adicional separada executada antes de qualquer outra consulta para essa sessão. Algo na linha de:

SqlConnection _Connection = new SqlConnection("{connection-string}");
_Connection.Open();

if(_IsConnectionContextRegistryKeySet)
{
  SqlCommand _Command = _Connection.CreateCommand();
  _Command.CommandType = CommandType.Text;

  _Command.CommandText = @"DECLARE @BinaryInfo VARBINARY(128);
                           SET @BinaryInfo = CONVERT(VARBINARY(128), @StringInfo);
                           SET CONTEXT_INFO @BinaryInfo;";

  SqlParameter _ParamInfo = new SqlParameter("@StringInfo", SqlDbType.VarChar, 100);
  _ParamInfo.Value = String.Format("{0} {1} {2}...", AXuserID, AXsessionID, ...);
  _Command.Parameters.Add(_ParamInfo);

  _Command.ExecuteNonQuery();
  _Command.Dispose();
}

Portanto, a pequena quantidade de sobrecarga adicional incorrida para permitir que essas informações sejam definidas vem da execução dessa consulta adicional.

Em segundo lugar, você pode testar o pool de conexões usando o SQL Server Profiler. Selecione o evento "RPC:Completed" na categoria "Stored Procedures", certifique-se de que "TextData", "ClientProcessID" e "SPID" estejam marcados para esse evento (no mínimo, você pode selecionar outras colunas, se desejar ). Em seguida, vá em "Filtros de coluna", selecione "TextData" e na condição "Curtir" adicione a seguinte condição: exec sp[_]reset[_]connection. Agora execute esse rastreamento. Se você vir instâncias de exec sp_reset_connection chegando, isso se deve ao uso do pool de conexões.

Além disso, há dois efeitos colaterais do pool de conexões que podem ou não aparecer nos DMVs, dependendo de quantas conexões estão sendo solicitadas. A consulta a seguir deve capturar muitas / a maioria das conexões agrupadas (observe que não tem nada a ver com CONTEXT_INFO):

SELECT sssn.login_time,
       DATEDIFF(MILLISECOND, conn.connect_time, sssn.login_time)
                  AS [MillisecondsBetweenConnectionAndSessionStart],
       conn.*
FROM sys.dm_exec_connections conn
INNER JOIN sys.dm_exec_sessions sssn
        ON sssn.session_id = conn.session_id
WHERE conn.session_id <> conn.most_recent_session_id
OR    DATEDIFF(MILLISECOND, conn.connect_time, sssn.login_time) > 50
ORDER BY conn.connect_time;

Esta consulta procura as seguintes indicações de uso do pool de conexões:

• O session_id atual não é o mesmo que o session_id anterior. Se esses dois IDs forem iguais, pode ou não ser uma conexão que está usando pooling, pois o mesmo SPID pode ser reutilizado. Mas, se forem diferentes, isso só pode ser o resultado do pool de conexões.
• O tempo entre o estabelecimento da conexão e o início da sessão é superior a 50 milissegundos (embora esse limite possa variar de acordo com o sistema). Normalmente, a primeira sessão a ser criada em uma conexão é inferior a 30 milissegundos após a conexão, mas "geralmente" não deve estar acima de 50, mesmo se estiver executando vários SqlCommands.

Em linhas semelhantes, também deve ser possível testar o pool de conexões criando uma tabela temporária e, a cada poucos segundos, capturando [session_id](INT) e [connection_id](UNIQUEIDENTIFIER) de sys.dm_exec_connections. Em seguida, basta procurar linhas que tenham o mesmo connection_id, mas diferentes session_id.

Por fim, a consulta postada na pergunta não é válida para indicar o pool de conexões com relação à maioria dos aplicativos da web. O problema aqui é que, normalmente, as propriedades de "program_name", "login_name" e "host_name" seriam as mesmas para todas as conexões feitas pelo servidor web/aplicativo (daí a necessidade dos modelos de licenciamento por processador/núcleo em vez de apenas ter o modelo CAL).

Em relação ao Pool de conexão, Thomas Stringer postou: http://blogs.msdn.com/b/sql_pfe_blog/archive/2013/10/08/connection-pooling-for-the-sql-server-dba.aspx

A coisa simples a saber é: "A resposta que os DBAs corporativos precisam dar a essas perguntas é que ela é específica do provedor. Em outras palavras, é no lado do cliente/aplicativo que o pool de conexões é tratado."

O CONTEXT_INFO, que é armazenado em binário, precisa ser definido pelo aplicativo. CONTEXT_INFO é apenas um pequeno depósito disponível para conter informações úteis, como o Nome/ID/Login do usuário. (Ou o que mais você quiser colocar no pequeno espaço disponível.)

A sobrecarga é pequena, mas é uma etapa extra para inserir e extrair os dados BINARY em CONTEXT_INFO. (Mas útil para sistemas que rodam sob uma conta de serviço, para que você possa saber de quem é a conexão no momento.)

Obrigado a srutzky por esclarecer que uma conexão em pool é redefinida, mas não é descartada. Pelo menos não imediatamente.

Uma postagem de Nacho Alonso Portillo oferece esclarecimentos: http://blogs.msdn.com/b/ialonso/archive/2012/06/04/how-to-determine-whether-a-connection-is-pooled-or-nonpooled .aspx

Em parte diz que o "sp_reset_connection... faz as seguintes tarefas: 1) limpa o contexto da sessão... que inclui... redefine o CONTEXT_INFO;... 2) notifica-os da ocorrência de um logout bem-sucedido.. . 3) inicia o processo de refazer o login."