Re: non-trivial finalize() on AbstractJdbc2Statement

Hi Vitalli

Yes my clients are definitely closing the PreparedStatements opened. In
fact we are using the hibernate query interface and I've been through the
code to make sure the close is been called in a finally block.
I agree that closing work done by the finalizer() method would actually
close the resource if its not closed. However the issue I'm raising is that
by having the non-trivial finalize() method, it adds every
PreparedStatement object created into the finalizer queue. And hence the a
GC not reclaiming all memory is should. So before the finalizer thread
(which is a low priority thread) gets to it, the application has ran out of
memory.

Cheers
-- Imran

On Mon, Feb 13, 2012 at 1:28 PM, Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>wrote:

> **
> Hello.
>
> While it would be better to handle resource closing with reference queues,
> are you sure your client does not leave resources unclosed? As for me,
> driver in finalize should do only work not done because of close not have
> been called correctly. In other words, your situation may be an indication
> of close not been called, and so driver does required work in finalize, so
> saturating finalize thread.
>
> Best regards, Vitalii Tymchyshyn
>
> 13.02.12 15:02, Imran написав(ла):
>
> Hi Dave
>
> Thanks for your response. I agree that this might not be widespread. And
> I haven't seen much mentions around this problem (hitting GC issues due to
> non-trivial finalize() methods) reported (based on my google searches).
> However, I guess the existence of it does provide the opportunity for this
> to happen as we've noticed. IMHO, encouraging clients to use the api
> as recommended (i.e. closing resources once they are done with them) is
> better than the driver allowing opportunity for bad things to happen. Or
> perhaps the driver caters to this kind of situation using WeakReference as
> oppose to using a non-trivial finalize().
>
> What are your thoughts?
>
> Cheers
> -- Imran
>
> On Mon, Feb 13, 2012 at 12:09 PM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
>
>> 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
>>
>
>
>