none
Pool de conexoes - autenticação Windows RRS feed

 > 

  • Pergunta

  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Boa noite, pessoal

    Um dúvida qto ao pool de conexões:

    Se minha string de conexão utiliza autenticação do sql (User ID e password), todos os acessos farão uso do pool (uma vez que a string de conexao é exatamente a mesma para todos os usuarios que usarem a aplicação).

    Agora, como funciona qndo utilizo autenticação integrada? O pool de conexões é criado/usado OU é criado um pool de conexões para cada usuário Windows acessando o banco?

    (Trabalho com o SQL 2005 Express - mencionar, por favor, se houver alguma diferença em relação ao mecanismo de pooling do 2008)

    Obrigado.


    Robson Castilho - Desenvolvedor C# - MCTS .Net 2.0 Windows Applications
    segunda-feira, 27 de abril de 2009 03:23
    |

Respostas

  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Boa Tarde,

    É isso aí...
    Só haveria pool se um mesmo usuário abrisse várias conexões, mas não haverá pool de conexões para usuários diferentes.

    Isso faz mais sentido para aplicações distribuídas ou Web. Se a aplicação é Desktop, cada conexão será criada em uma máquina própria e nesse caso não há como compartilhar as conexões entre os usuários. Ainda que você mudasse para a autenticação SQL não haveria como montar um pool. Em tese isso não é problema, pois, a "carga" de criação de conexões estaria dividida por todas as estações (o que não ocorreria em um servidor Web por exemplo)

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Piores Práticas - Uso do COUNT(*)
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!538.entry
    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 28 de abril de 2009 16:12
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Estamos chegando lá...

    A) Uma aplicação web em um Application Pool:

        1 - String única com autenticação SQL Server = Um único pool de conexões para TODAS as conexões
        2 - String única com autenticação integrada e o IIS personificando um usuário genérico "dominio\usrGenerico" para acessar o banco de dados = Um único pool de conexões para TODAS as conexões
        3 - String única com autenticação integrada e o IIS personificando o cliente na ponta = N pools de conexão de acordo com o número (N) de usuários que acessam o portal.


    B) Duas aplicações web em dois Application Pools:

        Mesmas regras acima se aplicam para CADA processo, definido no application pool. Então potencialmente teremos N*2 pools de conexões abertos somando os dois processos.

    C) Aplicação no cliente (winforms, por exemplo) com somente um processo

        1 - String única com autenticação SQL Server = Um único pool de conexões para TODAS as conexões disparadas por aquele processo
        2 - String única com autenticação integrada personificando o usuário que está executando o processo = Um único pool de conexões para TODAS as conexões abertas
        3 - String única com autenticação integrada personificando o usuário que está executando o processo + thread que roda em background e personifica outra conta = 2 pools de conexão, um para a identidade do usuário e outro pool para identidade personificada.

    Supondo o caso acima, se o usuário executar duas vezes o ".exe", no caso 3 teremos 4 pools abertos, sendo 2 em cada processo (pois são AppDomains diferentes).
    Sendo máquinas diferentes, aí não existe reuso nenhum do pool entre as máquinas, mas dentro do processo o pool vai existir e PODE ser útil.

    É impossível determinar o número exato de conexões mantidas pelo pool em cada processo (AppDomain), pois vai depender da demanda de cada aplicação, mas existem contadores que podem ser monitorados e pegando a média você pode ter uma idéia de quantas conexões ficarão abertas no SQL Server de acordo com o número de estações acessando a instância simultaneamente.

    Espero que agora tudo tenha ficado mais claro. :-)
    []s
    Luti


    luti
    quarta-feira, 29 de abril de 2009 20:27
    |

Todas as Respostas

  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Bom Dia,

    O Pool de conexão só ocorre se os parâmetros forem os mesmos (podem até ficar fora da ordem mas devem ser os mesmos). Se você utiliza um usuário SQL fixo há chances de aproveitar o pool de conexões. Se você utiliza a autenticação integrada (e normalmente através de logins e não de grupos) não haverá pool de conexões, pois, as conexões de um usuário não podem ser aproveitada por outro.

    O Pool de conexões é uma preocupação exclusiva da aplicação. Não há nada no SQL Server que deva ser configurado para que ele ocorra. Houve uma boa discussão do Pool de conexões em posts anteriores. Recomendo fazer uma pesquisa. Pode ser bem esclarescedor.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Piores Práticas - Uso do COUNT(*)
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!538.entry
    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 27 de abril de 2009 12:04
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Bom dia Gustavo,

    Deixa eu ver se ficou claro: quer dizer que em uma aplicação Windows Forms, em rede local, usando autenticacao integrada, o pool de conexoes nunca será usado. Entao a unica  forma de utilizar o pool nesta situação é mudar a string para autenticacao do SQL?
    Robson Castilho - Desenvolvedor C# - MCTS .Net 2.0 Windows Applications
    terça-feira, 28 de abril de 2009 15:35
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Boa Tarde,

    É isso aí...
    Só haveria pool se um mesmo usuário abrisse várias conexões, mas não haverá pool de conexões para usuários diferentes.

    Isso faz mais sentido para aplicações distribuídas ou Web. Se a aplicação é Desktop, cada conexão será criada em uma máquina própria e nesse caso não há como compartilhar as conexões entre os usuários. Ainda que você mudasse para a autenticação SQL não haveria como montar um pool. Em tese isso não é problema, pois, a "carga" de criação de conexões estaria dividida por todas as estações (o que não ocorreria em um servidor Web por exemplo)

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Piores Práticas - Uso do COUNT(*)
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!538.entry
    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 28 de abril de 2009 16:12
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Olá Gustavo,

    Obrigado pela explicação.

    A propósito, li o artigo sobre o Count(*) do seu blog, realmente muito bom e bem explicado. Depois irei olhar os demais posts.. Parabéns.

    []s
    Robson Castilho - Desenvolvedor C# - MCTS .Net 2.0 Windows Applications
    terça-feira, 28 de abril de 2009 16:48
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Olá Robson,

    Obrigado pelo elogio. Que bom que o artigo lhe agradou. Engraçado, pois, quando escrevei achei quase ninguém o comentaria e foi justamente o contrário.
    Tento atualizar pelo menos uma vez por semana. Espero que lhe seja muito útil.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Piores Práticas - Uso do COUNT(*)
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!538.entry

    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 28 de abril de 2009 17:00
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Bom dia pessoal, tudo bem?
    Gostaria de fazer algumas observacões nessa thread.

    Se não for especificado na string de conexão, um (ou mais) pool de conexões sempre será criado, seja aplicação ASP.NET, seja aplicação winforms.
    Quando você abre uma pool com uma string de conexão usando UID=xxxx e PWD=YYYY, a menos que haja em algum outro ponto da aplicação uma conexão com uma string diferente (que seja um espaço a mais), o SQL Server irá reutilizar o pool para todas as conexões.
    Quando você usa autenticação integrada com sua aplicação, o .NET vai criar um pool diferente para cada usuário, isto é, se você têm uma aplicação web que personifica o usuário para acessar o SQL Server e 100 usuários estão usando sua aplicação, você irá encontrar 100 pools diferentes. Basta usar os contadores do .NET Framework com o system monitor que isso ficará visível.
    O que temos que questionar é se vale a pena usarmos o pool com autenticação integrada, seja em uma aplicação web ou aplicação cliente. Mesmo em aplicações cliente existe uma demora sensível quando estamos abrindo uma nova conexão, então caso a aplicação execute muitas aberturas/fechamento de conexões, o pool pode ser útil.

    Enfim, essa é uma dúvida comum.
    Espero que no futuro seja possível reaproveitar o pool de conexões entre diferentes usuários com autenticação integrada, mas existem alguns detalhes para que isso seja possível.

    Abraços
    Luti
    http://luticm.blogspot.com
    luti
    terça-feira, 28 de abril de 2009 18:52
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Agora o negocio ficou contraditorio.

    O pool é client-side certo?
    Então a pergunta permanece, terei um pool de conexoes para cada usuario Windows logado ou o pool não é criado??

    (ps.: me referindo neste caso à aplicacao Windows com autenticação integrada.)
    Robson Castilho - Desenvolvedor C# - MCTS .Net 2.0 Windows Applications
    terça-feira, 28 de abril de 2009 19:01
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Oi Luti,

    Fiquei um pouco intrigado com esse parágrafo.

    "Se não for especificado na string de conexão, um (ou mais) pool de conexões sempre será criado, seja aplicação ASP.NET, seja aplicação winforms.
    Quando você abre uma pool com uma string de conexão usando UID=xxxx e PWD=YYYY, a menos que haja em algum outro ponto da aplicação uma conexão com uma string diferente (que seja um espaço a mais), o SQL Server irá reutilizar o pool para todas as conexões."

    Acho que da forma como está abre margem a duas dúvidas:

    Será que a string de conexão tem de ser mesmo idêntica, será que um espaço a mais irá desperdiçar o pool de conexões ?
    Essa parece ser uma conclusão um tanto óbvia, mas o link (SQL Server Connection Pooling Myths) desmente esse raciocínio. Em todo caso ele refere-se ao ADO e não ao ADO.NET. No ADO.NET a alteração de um espaço que seja deixará de aproveitar o pool ?

    Será mesmo que pode haver um reaproveitamento de conexões mesmo para aplicações Windows Form ?
    Penso que o pool de conexões é mantido em quem instancia as conexões e não no SQL Server. Como poderia um pool de conexões ser compartilhado em uma aplicação Windows Form se cada usuário está em uma estação diferente ? Além do fator localização, se o hostname é diferente, teoricamente a propria string de conexão repassaria o parâmetro WorkStationID com um valor diferente e o próprio SQL Server manteria linhas diferentes (seja na SysProcesses ou na sys.dm_exec_sessions. Como poderia entar haver um pool de conexões em uma aplicação Windows Form (compartilhado entre estações) ?

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Piores Práticas - Uso do COUNT(*)
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!538.entry

    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 28 de abril de 2009 19:08
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Sim, o pool fica no lado do cliente (da aplicação que está rodando), mas seu "cliente" do SQL Server pode ser uma aplicação winforms rodando na sua máquina ou então uma aplicação ASP.NET, concorda?
    Quando você está na sua máquina, como seu processo está executando com o token de segurança do seu usuário (por padrão), o .NET vai criar um pool de conexões para o seu usuário. Supondo que você dispare uma outra thread e modifique a identidade dessa thread, abrindo uma nova conexão integrada com o SQL Server, o processo do .NET (mesmo AppDomain), irá manter dois pools, um para seu usuário e outro para a identidade personificada. Se você disparar várias threads com o mesmo token de segurança, todas irão reutilizar um mesmo pool.
    Agora, se forem processos diferentes, serão dois AppDomains e cada um com seu pool de conexão, pois não existe reuso de pool entre processos.

    []s
    Luti
    luti
    • Sugerido como Resposta Luciano Moreira terça-feira, 28 de abril de 2009 19:15
    terça-feira, 28 de abril de 2009 19:13
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Gustavo

    Concordo com voce sobre o questionamento "como poderia um pool de conexoes ser compartilhado em uma aplicacao Windows Form se cada usuario esta em uma estacao diferente" .... Concordo que NAO, uma vez que o pool é mantido pelo cliente e nao pelo SQL Server.....

    Mas minha dúvida (talvez seja bobagem total) é saber se mesmo assim, não é criado um pool somente para aquele usuario (ou seja eles nao compartilham um pool, cada um tem o seu)

    []s
    Robson Castilho - Desenvolvedor C# - MCTS .Net 2.0 Windows Applications
    terça-feira, 28 de abril de 2009 19:13
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Oi Luti,

    Agora sim eu entendi. Uma aplicação em uma estação pode ter um pool próprio e reaproveitar as conexões feitas por essa aplicação naquela estação. Se vários usuários de estações diferentes utilizam a mesma aplicação, eles não compartilharão as mesmas conexões, pois, se trata de conexões diferentes já que seus tokens e processos são diferentes. Embora tenham seus pools de conexões "privados" não irão compartilhar conexões já que as estações de trabalho são diferentes.

    Se estivéssemos falando de um servidor Web, uma vez que os clientes conectam-se a ele, caberá ao servidor Web instanciar as conexões e nesse caso, mesmo os usuários estando em estações separadas, o pool torna-se compartilhado (desde que obedecidas as condições para o pool), pois, quem instancia e gerencia as conexões nesse caso é o servidor Web.

    Nesse caso pode-se afirmar que toda conexão representa um pool de conexões mesmo que esse pool limite-se a um única conexão.

    É isso mesmo ?

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Piores Práticas - Uso do COUNT(*)
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!538.entry

    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 28 de abril de 2009 19:45
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Sabia que este post seria interessante!

    Luti, confirme aí.

    []s
    Robson Castilho - Desenvolvedor C# - MCTS .Net 2.0 Windows Applications
    terça-feira, 28 de abril de 2009 22:24
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Estamos chegando lá...

    A) Uma aplicação web em um Application Pool:

        1 - String única com autenticação SQL Server = Um único pool de conexões para TODAS as conexões
        2 - String única com autenticação integrada e o IIS personificando um usuário genérico "dominio\usrGenerico" para acessar o banco de dados = Um único pool de conexões para TODAS as conexões
        3 - String única com autenticação integrada e o IIS personificando o cliente na ponta = N pools de conexão de acordo com o número (N) de usuários que acessam o portal.


    B) Duas aplicações web em dois Application Pools:

        Mesmas regras acima se aplicam para CADA processo, definido no application pool. Então potencialmente teremos N*2 pools de conexões abertos somando os dois processos.

    C) Aplicação no cliente (winforms, por exemplo) com somente um processo

        1 - String única com autenticação SQL Server = Um único pool de conexões para TODAS as conexões disparadas por aquele processo
        2 - String única com autenticação integrada personificando o usuário que está executando o processo = Um único pool de conexões para TODAS as conexões abertas
        3 - String única com autenticação integrada personificando o usuário que está executando o processo + thread que roda em background e personifica outra conta = 2 pools de conexão, um para a identidade do usuário e outro pool para identidade personificada.

    Supondo o caso acima, se o usuário executar duas vezes o ".exe", no caso 3 teremos 4 pools abertos, sendo 2 em cada processo (pois são AppDomains diferentes).
    Sendo máquinas diferentes, aí não existe reuso nenhum do pool entre as máquinas, mas dentro do processo o pool vai existir e PODE ser útil.

    É impossível determinar o número exato de conexões mantidas pelo pool em cada processo (AppDomain), pois vai depender da demanda de cada aplicação, mas existem contadores que podem ser monitorados e pegando a média você pode ter uma idéia de quantas conexões ficarão abertas no SQL Server de acordo com o número de estações acessando a instância simultaneamente.

    Espero que agora tudo tenha ficado mais claro. :-)
    []s
    Luti


    luti
    quarta-feira, 29 de abril de 2009 20:27
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Oi Luti,

    Acho que agora está 100%. Era exatamente esse o meu entendimento (só não me expressei tão bem).

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Piores Práticas - Uso do COUNT(*)
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!538.entry
    Classifique as respostas. O seu feedback é imprescindível
    quarta-feira, 29 de abril de 2009 21:05
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Olá pessoal,

    Muito obrigado pela atenção em responder tão detalhadamente.

    Valeu mesmo.

    []s
    Robson Castilho - Desenvolvedor C# - MCTS .Net 2.0 Windows Applications
    quarta-feira, 29 de abril de 2009 22:57
    |