Re: How not to use JDBC (JDBC Performance Scale 15x presentation)

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?
>

In response to

Responses

Browse pgsql-jdbc by date

  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)