Re: How not to use JDBC (JDBC Performance Scale 15x presentation) - Mailing list pgsql-jdbc

From Dave Cramer
Subject Re: How not to use JDBC (JDBC Performance Scale 15x presentation)
Date
Msg-id CADK3HHK6WAEyZ8FFvF-NBS3oi25jhTvoiJ25rwrR+K803h=3_g@mail.gmail.com
Whole thread Raw
In response to [JDBC] How not to use JDBC (JDBC Performance Scale 15x presentation)  (Jorge Solórzano <jorsol@gmail.com>)
Responses Re: How not to use JDBC (JDBC Performance Scale 15x presentation)  (Jorge Solórzano <jorsol@gmail.com>)
Re: How not to use JDBC (JDBC Performance Scale 15x presentation)  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Re: How not to use JDBC (JDBC Performance Scale 15xpresentation)  (Dirk Olmes <dirk.olmes@exentra.de>)
List 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.


On 15 March 2017 at 17:07, Jorge Solórzano <jorsol@gmail.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?

pgsql-jdbc by date:

Previous
From: Jorge Solórzano
Date:
Subject: How not to use JDBC (JDBC Performance Scale 15x presentation)
Next
From: Jorge Solórzano
Date:
Subject: Re: [JDBC] How not to use JDBC (JDBC Performance Scale 15x presentation)