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

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: How not to use JDBC (JDBC Performance Scale 15x presentation)
Дата
Msg-id CADK3HHK6WAEyZ8FFvF-NBS3oi25jhTvoiJ25rwrR+K803h=3_g@mail.gmail.com
обсуждение исходный текст
Ответ на [JDBC] 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)
Re: How not to use JDBC (JDBC Performance Scale 15x presentation)
Re: How not to use JDBC (JDBC Performance Scale 15xpresentation)
Список 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 по дате отправления:

Предыдущее
От: Jorge Solórzano
Дата:
Сообщение: How not to use JDBC (JDBC Performance Scale 15x presentation)
Следующее
От: Jorge Solórzano
Дата:
Сообщение: Re: [JDBC] How not to use JDBC (JDBC Performance Scale 15x presentation)