| From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
|---|---|
| To: | Joseph Hammerman <jhammerman(at)squarespace(dot)com> |
| Cc: | pgsql-jdbc(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Recommendations for PGBouncer interacting with HikariCP |
| Date: | 2019-08-23 20:39:07 |
| Message-ID: | CADK3HHK3WEEfFda4jTO0J2akREJVdG1SH1kq6ddkc9FUYN=Q3A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
On Wed, 21 Aug 2019 at 21:03, Joseph Hammerman <jhammerman(at)squarespace(dot)com>
wrote:
> Hi pgsql-jdbc email distribution list,
>
> We have recently added PGBouncer into our stack. We have done this in
> part, to protect the database. Our Java userbase is accustomed to using
> HikariCP / Hibernate for connection pooling. They would prefer to continue
> to use the connection pooler, in order to not have GC churn on connection
> spin up and tear down (in addition to additional latency introduced by
> having to perform the three-way handshake more often).
>
> Is there any published material / does anyone have any knowledge of how
> these tools should interact or not interact?
>
JDBC should work fine with pgbouncer.
> HikariCP wants to keep many long running idle_in_transaction connections
> open, which saturates the backend connection pool.
>
That's strange why is it keeping them in transaction ? One would think once
you closed (returned the connection) it should commit it.
>
> Thanks in advance for any assistance anyone can provide,
> Joe
>
Dave Cramer
davec(at)postgresintl(dot)com
www.postgresintl.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steven Schlansker | 2019-08-23 21:53:59 | Re: Recommendations for PGBouncer interacting with HikariCP |
| Previous Message | Dave Cramer | 2019-08-23 10:25:15 | Re: Procedure support improvements |