Re: non-trivial finalize() on AbstractJdbc2Statement

Well this is a typical which is worse case scenario. People leaking
resources because they don't explicitly close them, or your case ? I'm
not sure which is worse.

Given that the driver is being used in many very high throughput sites
without this problem, I'm curious as to why nobody else has complained

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Fri, Feb 10, 2012 at 12:39 PM, Imran <imranbohoran(at)gmail(dot)com> wrote:
> Hello
>
> We've been having OOM errors in our applications through GC overhead limits
> under heave load resources running queries. Inspecting the heap dump, it
> appears that the finalizer queue is taken up most of the heap space. Almost
> all of the the finalizer objects I've seen seem to have a
> jdbc3PreparedStatement object in it. Going through the source code of the
> driver I see that the 'AbstractJdbc2Statement' has a non-trivial finalize
> method. I guess this explains why these objects end up in the finalizer
> queue. Can I clarify the need to having this finalize() method here? It
> seems to be calling the close() method of the statement which I would have
> thought is the responsibility of the client building a Statement object. Is
> there any chance this can be dropped so we don't see these objects ending up
> in the finalizer queue under heavy load and the jvm running out of memory
> before the GC threads gets around to 'actually' reclaim the memory?
>
> Also we are using postgres 9.0.4 and the 8.3-604.jdbc3 version of the
> postgresql jdbc driver.
>
> Cheers
> -- Imran