I am not big fan of finalizes. But you propose to remove mechanism that works most times, without introducing anything else.
You are saying that as in my incorrect application (and I am 95% sure you've got incorrect application if you are getting finalizing objects piled up) it does not work, let's remove it altogether and make driver also wrong.
Look, java pretty much guaranties garbage collecting, being it heap objects or out of heap objects like files or sockets. And you propose to introduce out-of-heap leak in the driver. I am very strongly against it.
P.S. If we will start talking about Errors, like OOM, any application should be considered broken after almost any Error being thrown, no matter if it's thrown in the finalized thread or not.
23 жовт. 2013 08:59, користувач "Heiko W. Rupp" <
hwr@pilhuhn.de> написав:
Vitalii,
Am 23.10.2013 um 02:36 schrieb Vitalii Tymchyshyn:
> 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.
*relying* on Finalizers to clean up server side state may introduce those leaks in the first place, as
finalizers are not guaranteed to be called at all.
In my case we had 290k Statements in the queue to be finalized, when the JVM started to throw
OutOfMemoryErrors. At that point no one will those finalize() methods be called here.
Also there is no guarantee when the finalizer runs other than after completed construction
and before the memory is finally released by the garbage collector.
Objects to be finalized could thus hold references to pg-server side resources for hours,
which is not what you want for short lived simple statements.
And as Dave said, Statements are supposed to be explicitly close()d by the application.
