On 09-10-2015 11:04, Flavio Henrique Araque Gurgel wrote: > > Se o colega tem uma aplicação Web escrita em Java, provavelmente ela > roda dentro de um Tomcat ou outro servidor de aplicações similar. > Nesses casos, cuidado com o PgBouncer: o driver JDBC usa em muitos casos > prepared statements que *não* são compatíveis com o modo transaction do > PgBouncer, somente o modo connection. Dá pra configurar do lado do JDBC > todavia. >
Vc quis dizer o modo do pool "session"... para manter 100% de compatibilidade, ou seja, todas features como se não existisse um pool na frente esse modo deve ser utilizado, caso contrário deve-se observar o que consta em [1]. > Nesses casos, também, normalmente o servidor de aplicações já possui um > pool de conexões que pode ser facilmente configurado, com a vantagem de > reportar suas atividades para as threads que pedem por conexões. Quando > isso ocorre, colocar mais um pool não traz nenhuma vantagem e, pelo > contrário, pode até piorar as coisas e causar erros que você não > compreenderá. > Se bem ajustado (Ex: pool do JBoss + PGBouncer) podemos ter uma vantagem sim, que é a possibilidade fazer manutenções com downtime mínimo, e nestas inclusive atualização de binários (ontem saiu 9.4.5, 9.3.10, 9.2.14, 9.1.19 e 9.0.23). Como no pgbouncer conseguimos criar aqueles "virtual databases" conseguimos segmentar as aplicações dessa forma criando pools separados, e com isso podemos fazer um "PAUSE" em um determinado pool que pertence a uma aplicação para, por exemplo, executar um pg_repack para recriar datafiles inchados... enfim, é apenas um caso de uso. Att, [1] https://pgbouncer.github.io/features.html -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
signature.asc
Description: OpenPGP digital signature
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
