Thread: [JDBC] How not to use JDBC (JDBC Performance Scale 15x presentation)
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?
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?
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?
I mean connection leaks, and when a connection is closed the recommended approach is to close the ResultSets and Statements before.
Ok, I get your point, you mean to reuse the statement in a loop.
Thanks for your quick response.
Jorge Solórzano
On Wed, Mar 15, 2017 at 3:13 PM, Dave Cramer <pg@fastcrypt.com> wrote:
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?
I mean connection leaks, and when a connection is closed the recommended approach is to close the ResultSets and Statements before.
Ok, I get your point, you mean to reuse the statement in a loop.
Thanks for your quick response.
Jorge Solórzano
On Wed, Mar 15, 2017 at 3:13 PM, Dave Cramer <pg@fastcrypt.com> wrote:
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?
Is the presentation available online somewhere?
Vladimir
Re: [JDBC] How not to use JDBC (JDBC Performance Scale 15x presentation)
From
Vladimir Sitnikov
Date:
Is the presentation available online somewhere?
Vladimir
Jorge Solórzano
On Wed, Mar 15, 2017 at 3:25 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Is the presentation available online somewhere?Vladimir
Jorge Solórzano
On Wed, Mar 15, 2017 at 3:25 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Is the presentation available online somewhere?Vladimir
please provide feedback, I'm giving the same talk at pgconf in nyc
On 15 March 2017 at 17:29, Jorge Solórzano <jorsol@gmail.com> wrote:
Jorge SolórzanoOn Wed, Mar 15, 2017 at 3:25 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Is the presentation available online somewhere?Vladimir
please provide feedback, I'm giving the same talk at pgconf in nyc
On 15 March 2017 at 17:29, Jorge Solórzano <jorsol@gmail.com> wrote:
Jorge SolórzanoOn Wed, Mar 15, 2017 at 3:25 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Is the presentation available online somewhere?Vladimir
> 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. Well we actually do this in our app. It's a bit of a corner case where we have a custom persistence layer that keeps a "read" and a "write" connection open all the time. WRT to not closing the statements - isn't that what connection pools do? They wrap the Connnection instance from the JDBC driver with an implementation that shortcuts close() and just returns the connection to the pool. -dirk
> 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. Well we actually do this in our app. It's a bit of a corner case where we have a custom persistence layer that keeps a "read" and a "write" connection open all the time. WRT to not closing the statements - isn't that what connection pools do? They wrap the Connnection instance from the JDBC driver with an implementation that shortcuts close() and just returns the connection to the pool. -dirk