On 23 October 2013 11:06, Vitalii Tymchyshyn <vit@tym.im> wrote:
> As for me, introducing server-side leak would be plain wrong. If it will be
> done, please announce in the list, I will stop recommending using postgresql
> in java projects.
It's not even clear that leaked (aka non-closed) java statement
objects will even have any impact - see Heikki's email which points
out that they don't actually correspond to real pgsql server
resources.
The current finalizer on statement objects just calls the close()
method. All java code which uses JDBC should be calling close() on
created statement objects explicitly in a finally block, or using a
framework which does that automatically. To not call close() on a
statement object is a bug in the calling code. The existing finalizer
is trying to save users from the possible bad effects of such a bug in
their code, but it's not clear what those effects are, and the
finalizer clearly has a non-zero performance cost in some situations
(that's what kicked off the thread). So users whose code is doing the
right thing may be getting penalized for the sake of saving other
users with buggy code.
I suggested a way to remove the cost of the finalizer while still
allowing users to switch the old behaviour back on using a parameter,
but as I said it's a bit ugly code-wise.
We need to determine whether not calling close() on thrown-away
statement objects actually causes any real resource leaks or not.
Without that info we don't know what the trade-offs are.
Cheers
Tom