Dúvida Conceitual - Classe de Conexão Singleton

Em vez de ter um Singleton contendo uma única conexão, o ideal é ter um Singleton contendo um pool de conexões - ou seja, a arquitetura deixa de ser “apenas uma conexão para todos os usuários” para ser “apenas um pool de conexões para todos os usuários”. A biblioteca C3P0 é excelente para gerenciar pools de conexões:

Essa também é a biblioteca padrão que o Hibernate usa para gerenciar conexões.

Sim… eu ja conhecia a respeito do Pool de conexões. Então o que eu pensei é valido ne… o pool é justamente pra evitar isso.

TiD:

Pessoal,

estive pensando sobre a utilização de uma classe de conexão Singleton em uma aplicação web e fiquei com algumas duvidas que gostaria de discutir com voces.
As vantagens de utilizar uma classe singleton para encapsular a conexão com o banco de dados todos conhecemos.. porem em uma aplicação web, imagine um site com o submarino por exemplo. Quantos usuarios concorrentes e transações não ocorrem ali por minuto, sei la.. é um site em que o banco de dados é exigido massivamente.

Se a minha classe de conexão é singleton então teoricamente tenho uma conexão com o banco de dados disponível para TODA a aplicação, certo ? A questão é: se TODOS utilizam apenas aquele canal de conexão que está na memória, não fica lento em um sistema como o dito acima ? Supondo que 10 pessoas estão comprando quase que ao mesmo tempo.. essas 10 requisições vao ao BD sequencialmente ou rola algum tipo de paralelização ? Ao meu ver vão sequencialmente pois o canal é único, daí o possível gargalo. Em aplicação web isso é passivel de consideração visto os inúmeros acessos concorrentes.

E aí, o que voces acham ?

oi

uma coisa é você diminuir a numero de alocação de objetos na heap - o que você consegue com o Singleton- e outra é você manter ativas várias conexões com o banco - o que você consegue com o pool de conexões

se eu tiver algo assim

class Conexao {

  private Connection conn;

  public Connection getConnection() {
    return new Connection();
  }
}

da mesma forma você vai ter como recuperar uma conexão disponivel para toda a aplicação

Geralmente se cria um pool de conexão para cada string de conexão onde um algoritimo associa itens no pool baseado exatamente na string de conexão; quando o pool é criado são criados objetos de conexão e incluídos no pool para satisfazer o requisito mínimo de tamanho do pool especificado.

Quando uma conexão é requisitada por uma aplicação e o tamanho máximo do pool foi alcançado , a requisição é enfileirada e fica aguardando até que uma conexão seja liberada para uso. A liberação de uma conexão ocorre quando ela é fechada ou liberada , neste momento ela é re-alocada ao pool para ser utilizada novamente. O pool de conexões gerencia as conexões que expiraram e/ou que foram liberadas/fechadas.

http://imasters.uol.com.br/artigo/3033/dotnet/usando_connection_pooling/

Ou seja, a vantagem que você ganha usando o pool é não precisa ficar abrindo e fechando conexões com o banco toda hora que receber uma requisição

André, de fato !

O custo maior não é nem o de ter várias conexões abertas visto que os SGBDs de hoje já suportam isso com um pé nas costas - a questão é não ficar abrindo e fechando conexão o tempo todo, o que de fato é custoso. Daí o pool resolve, pois as conexões já estão abertas e você aloca uma para cada request. Não é isso ?

Valeu!