Quantas conexões JDBC em Java?

Question

Eu tenho um programa Java que consiste de cerca de 15 métodos. E, estes métodos se invocado muito freqüentemente durante a exeuction do programa. No momento, eu estou criando uma nova conexão em cada método e invocando declarações sobre eles (banco de dados está configurado em outra máquina na rede).

O que eu gostaria de saber é: Devo criar apenas uma conexão no método principal e passá-lo como um argumento para todos os métodos que exigem um objeto de conexão, uma vez que reduziria significativamente o número de conexões objeto no programa, em vez de criar e fechar conexões com muita freqüência em cada método.

Eu suspeito que eu não estou usando os recursos de forma muito eficiente com o design atual, e não há muito espaço para melhorias, considerando que este programa pode crescer muito no futuro.

Answer 1

Sim, você deve considerar a reutilização de conexões em vez de criar um novo a cada vez. O procedimento habitual é:

• fazer algum palpite quanto ao número de conexões simultâneas seu banco de dados pode sensatamente lidar com (por exemplo, começar com 2 ou 3 por CPU na máquina de banco de dados até você descobrir que este é muito pouco ou muito many-- ele vai tendem a depender sobre como disco-bound suas consultas são)
• criar um piscina a isso muitas conexões: essencialmente uma classe que você pode pedir para "a próxima conexão livre" no início de cada método e, em seguida, "passar de volta" para a piscina no final de cada método
• seu getFreeConnection () necessidades método para retornar uma ligação gratuita se estiver disponível, outra pessoa ou (1) criar um novo, até o número máximo de conexões que você decidiu licença, ou (2) se o máximo já estão criadas, esperar por um para se tornar livre
• Eu recomendo a classe Semaphore para gerenciar as conexões; Na verdade, tenho um pequeno artigo em meu site em gestão de um pool de recursos com um Semaphore com um exemplo que eu acho que você poderia adaptar-se a sua finalidade

Um par de considerações práticas:

• Para um melhor desempenho, você precisa ter cuidado não "porco" uma ligação, enquanto você não está realmente usá-lo para executar uma consulta . Se você pegar uma conexão do pool de uma vez e, em seguida, passá-lo para vários métodos, você precisa ter certeza de que você não está acidentalmente fazer isso.
• Não se esqueça de retornar suas ligações para a piscina! (Try / finally é seu amigo aqui ...)
• Em muitos sistemas, você não pode manter conexões abertas 'para sempre' : o O / S vai fechá-los depois de algum tempo máximo. Assim, no seu 'retornar uma conexão com o pool' método, você precisa pensar sobre conexões 'aposentar' que estiveram ao redor por um longo tempo (configuração em algum mecanismo para lembrar, por exemplo, por ter objeto wrapper em torno de um objeto de conexão JDBC real que você pode usar para armazenar métricas como este)
• Você pode querer considerar o uso de declarações preparadas.
• Com o tempo, você provavelmente vai precisar de ajustar o tamanho do pool de conexão

Answer 2

Você pode passar na conexão ou ainda melhor usar algo como Connection Jakarta banco de dados Pooling. http://commons.apache.org/dbcp/

Answer 3

Você deve usar um pool de conexão para isso.

Dessa forma, você poderia pedir a conexão e liberá-lo quando você estiver acabamento com ela e devolvê-lo à piscina

Se outro segmento quer uma nova conexão e que um está em uso, um novo pôde ser criado. Se nenhuma outra thread está usando uma conexão a mesma poderia ser reutilizado.

Desta forma, você pode deixar seu aplicativo de alguma forma a maneira como ele é (e não passar a conexão todo) e ainda usar os recursos corretamente.

Infelizmente primeira classe ConnectionPools não são muito fáceis de usar em aplicações independentes (que são o padrão em servidores de aplicação) Provavelmente um microcontainer (como Sping) ou um quadro bom (como Hibernate) poderia deixá-lo usar um.

Eles não são muito difíceis de um código a partir do zero embora.

:)

pesquisa Esta google vai ajudar -lo a encontrar mais sobre como usar um.

Skim através

Answer 4

Muitos drivers JDBC fazer pool de conexão para você, então há pouca vantagem fazendo pooling adicional neste caso. Eu sugiro que você verifique a documentação para você driver JDBC.

Outra abordagem para pools de conexão é

• Tem uma conexão para todo o acesso de banco de dados com acesso sincronizado. Isso não permite a simultaneidade, mas é muito simples.
• Loja as conexões em uma variável ThreadLocal (override initialValue ()) Isso funciona bem se houver um pequeno número fixo de threads.

Caso contrário, eu sugiro usar um pool de conexão.

Answer 5

Se o seu aplicativo é single-threaded, ou faz todas as suas operações de banco de dados a partir de um único segmento, é ok para usar uma única conexão. Supondo que você não precisa de múltiplas conexões para qualquer outro motivo, este seria, de longe, a implementação mais simples.

Dependendo do seu motorista, que também pode ser viável para compartilhar uma conexão entre segmentos - isso seria ok também, se você confiar em seu driver não mentir sobre sua thread-segurança. Consulte a documentação do driver para obter mais informações.

Normalmente os objetos abaixo "Connection" não pode ser utilizada com segurança de vários segmentos, por isso geralmente não é aconselhável para compartilhar ResultSet, objetos Declaração etc entre segmentos - de longe a melhor política é usá-los na mesma discussão que os criou; este é normalmente fácil, porque esses objetos não são geralmente mantidos por muito tempo.