From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Jorge Solórzano <jorsol(at)gmail(dot)com> |
Cc: | List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: How not to use JDBC (JDBC Performance Scale 15x presentation) |
Date: | 2017-03-15 21:13:19 |
Message-ID: | CADK3HHK6WAEyZ8FFvF-NBS3oi25jhTvoiJ25rwrR+K803h=3_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Hi Jorge,
Many people do very unusual things such as create a statement for every
iteration of the loop.
I think you are correct that keeping the statement open for the life of the
app is a bit of a stretch but ideally as long as possible.
OTOH, what leaks are you referring to ? Statements end up being server
prepared statements which should not leak.
Dave Cramer
davec(at)postgresintl(dot)com
www.postgresintl.com
On 15 March 2017 at 17:07, Jorge Solórzano <jorsol(at)gmail(dot)com> wrote:
> Hi Dave,
>
> In your JDBC presentation at Scale 15x you mention that the best solution
> to get advantage of caching is to never close the statements if possible,
>
> How that works? I normally (and most people I think) do a open - close
> approach, and it's probably the best practice I think (to avoid leaks). So
> how can a statement remain open for the lifespan of the application?
>
> I mostly use applications in the context of application servers, where
> they have connection pools and their own statement cache, so is valid to
> "enable" the statement cache of the application server and expect that the
> driver internally use them?
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jorge Solórzano | 2017-03-15 21:24:46 | Re: How not to use JDBC (JDBC Performance Scale 15x presentation) |
Previous Message | Jorge Solórzano | 2017-03-15 21:07:47 | How not to use JDBC (JDBC Performance Scale 15x presentation) |