Tenho uma pequena duvida.
Tenho uma pequena aplicação desktop, onde toda regra de negocio e conexão com banco de dados fica dentro de um jar.
Cada usuario tem esse .jar na sua maquina.
Adianta eu cria um pool de conexões no .jar, ja que cada usuario estará rodando na sua maquina?
O .jar é o cliente/servidor, so o banco de dados que estara numa unica maquina.
Em 99,99% das aplicações ter esse pool não serviria de nada a não ser consumir recursos da máquina desktop.
Porém se esta aplicação, mesmo sendo desktop, precisar paralelizar muito processamento e a espera pela liberação da conexão com o banco estiver travando o meio de campo, aí sim o pool é bem vindo. Sinceramente, duvido que este seja o caso.
[quote=marciosilva1974]Em 99,99% das aplicações ter esse pool não serviria de nada a não ser consumir recursos da máquina desktop.
Porém se esta aplicação, mesmo sendo desktop, precisar paralelizar muito processamento e a espera pela liberação da conexão com o banco estiver travando o meio de campo, aí sim o pool é bem vindo. Sinceramente, duvido que este seja o caso.
[/quote]
Como não? O pool serve para:
- Evitar abrir e fechar várias vezes a mesma conexão (especialmente se vc usa um framework como Spring, que fecha a conexão sozinha);
- Garantir que múltiplas threads utilizem conexões diferentes de maneira transparente;
- Gerir automaticamente conexões mortas pelo banco de dados;
- Fechar conexões caso a aplicação fique ociosa.
Um pool é tão absurdamente simples de implementar, que mesmo numa aplicação desktop eu não deixaria de usá-lo.
Como os prezados acima, vai muito da relação da aplicação com o BD.
As necessidades da aplicação devem ser muito específicas para exigir um pool de conexão.
Na maioria dos casos um aplicação desktop necessitaria de apenas uma conexão e não de várias.
Acho que só aplicações de faculdade não exigem um pool de conexões.
Se esse é o seu caso, sinta-se à vontade para não usar o pool, e até mesmo para usar um singleton horrível com a sua conexão sempre aberta (argh).
Consome um caminhão de recursos, e deixar recursos abertos para sempre costuma a ser uma péssima prática de programação, mas, enfim, só haverá um usuário usando o banco mesmo…
[quote=ViniGodoy][quote=marciosilva1974]Em 99,99% das aplicações ter esse pool não serviria de nada a não ser consumir recursos da máquina desktop.
Porém se esta aplicação, mesmo sendo desktop, precisar paralelizar muito processamento e a espera pela liberação da conexão com o banco estiver travando o meio de campo, aí sim o pool é bem vindo. Sinceramente, duvido que este seja o caso.
[/quote]
Como não? O pool serve para:
- Evitar abrir e fechar várias vezes a mesma conexão (especialmente se vc usa um framework como Spring, que fecha a conexão sozinha);
- Garantir que múltiplas threads utilizem conexões diferentes de maneira transparente;
- Gerir automaticamente conexões mortas pelo banco de dados;
- Fechar conexões caso a aplicação fique ociosa.
Um pool é tão absurdamente simples de implementar, que mesmo numa aplicação desktop eu não deixaria de usá-lo.
[/quote]
Vini, vc tá certo. É que eu quis dizer em 99,99% das aplicações desktop.
Abs,
e para o meu caso, em que eu uso uma conexão diferente para cada usuario do sistema ( cada usuario do sistema, tem um login ( usuario, password) diferente de acesso a base de dados) para poder controlar os previlegios de acesso a nivel dos previlegios do SGBD.
Pool de conexões é necessario ?? acho que fica meio complicado para este caso, que um usuario nunca vai usar a conexão de outro usuario.
Um mesmo usuário, se tiver 2 threads, poderá exigir duas conexões diferentes no banco. Por exemplo, ele poderia ter uma conexão tratando a geração de um relatório pesado, enquanto continua trabalhando na aplicação.
Além disso, é interessante que um usuário que simplesmente deixou a máquina ligada com seu aplicativo aberto feche suas conexões com o banco em algum momento. Não tem porque ele ocupar recursos do banco de dados se está ocioso, e isso pode gerar um problema sério de escalonamento do seu sistema, caso ele passe a ser usado por muitos usuários (note aqui que o pool ajuda a poupar um recurso caro, que é o de banco, ao custo de um recurso barato, que é um pouco de processamento e memória na máquina de seu usuário).
Finalmente, é importante tratar as conexões que o banco pode fechar arbitrariamente, por exemplo, caso o usuário tenha usado o recurso de hibernar e, para o banco, tenha ficado por horas inativo.
O pool trata todas essas situações automaticamente. Ele permita que você trate os recursos da maneira correta que é através do ciclo de:
- Requisição
- Uso
- Liberação
Assim, garante-se que se a aplicação não estiver usando um recurso, ele está livre (ou pronto para ser liberado).
Por isso discordo que 99.99% das aplicações desktop não deveriam usar um pool. Na verdade, já vi muitos males gerados pelo design pobre de se manter um singleton para a conexão durante todo o ciclo de vida do software.
Isso aí é software de faculdade, não deveria ser usado na indústria. Em aplicações sérias, prefira soluções robustas e escaláveis.
Vini, pode fazer a gentileza de postar o código da forma que você costuma utilizar para servir de base para os que estão com essa dificuldade?
Bom, eu estou usando pool de conexões por desencargo, mas a dúvida persiste.
Pelo seguinte: Cada máquina terá o .jar nela, qdo usuario abrir a aplicação (q não requer usuário e senha), e abrir qq tela estará “gerando” um pool (acho q é assim).
Se um segundo usário abrir, estará gerando outro pool e assim por diante.
Funciona assim mesmo ou o primeiro usuario cria esse pool eo banco fica gerenciando?
[quote=avsouza]Bom, eu estou usando pool de conexões por desencargo, mas a dúvida persiste.
Pelo seguinte: Cada máquina terá o .jar nela, qdo usuario abrir a aplicação (q não requer usuário e senha), e abrir qq tela estará “gerando” um pool (acho q é assim).
Se um segundo usário abrir, estará gerando outro pool e assim por diante.
Funciona assim mesmo ou o primeiro usuario cria esse pool eo banco fica gerenciando? [/quote]
Funciona assim mesmo, cada instância do programa rodando tem seu próprio pool, eu acho essencial ter um pool de conexões.
Uma coisa que acho importante configurar é o número mínimo de conexões que ele deixa aberta no pool, se vc identificar que no seu programa normalmente o seu usuário não precisa de mais de 5 conexões ao mesmo tempo, não tem muito sentindo deixar o pool configurado com o número mínimo de conexões abertas maior do que isso…
humm, blz, vlw pessoal, foi boa a discusão.
um abraço