Re: non-trivial finalize() on AbstractJdbc2Statement

@Vitalli - w.r.t Thread priority, I've tried to get the priority off the
jvm I'm running, but the thread dump nor jconsole/jvisualvm is giving this
out to me. We run 1.6.0_12 on a 64bit linux platform. jvisualvm however
shows that the Running percentage of the Finalizer thread is comparatively
low. To my knowledge Finalizer thread is low by default, and looking at the
Finalizer code, it does appear to be setting the priority to MAX_PRIORITY -
2.
Anyways that aside, heap dumps I've collected when we had OOMs have pointed
at high Finalizer objects and the referent of those have been jdbc3Satement
objects, which is why I raised this question. I'm not sure if its common
practice to always use finalize() for any mop-up tasks, as I've seen other
cautions raised around it, although I can see there are valid cases to do
so.

@Dave - I have done this and as mentioned in the previous post, I haven't
run into the OOM issues under similar load.

Cheers
-- Imran

On Wed, Feb 15, 2012 at 11:42 AM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:

> On Wed, Feb 15, 2012 at 6:30 AM, Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>
> wrote:
> > Hello.
> >
> > The finalizer thread is not a low priority thread in my JVM (openjdk)
> and as
> > soon as Statement.close does nothing (and it does nothing if statement is
> > closed), I don't see how can it be a problem to free memory. Actually
> > statement creation is much more heavy thing than "if (flag) return". It's
> > perfectly valid to close native resource (and as far as I know statement
> > allocates server-side native resources) in finalizer. Another
> implementation
> > can be to create a ReferenceQueue and a bunch of References that should
> be
> > checked now and then during connection calls, but this introduces
> additional
> > processing that is not needed most time. You can't drop this code
> altogether
> > as while it's good practice to close statements in client code, you can't
> > guarantee it's done everywhere. Actually it's common practice in java to
> > clean-up external resources in finalize, see for example
> FileOutputStream.
> > As of your problem, I don't thing statement finalize method is the
> problem
> > cause. I can see two causes:
> > 1) The code bug mentioned in this thread
> > 2) Some another class with long finalize method. This is the case that
> can
> > lead to confusion. Say, you have an object created once in 5 minutes that
> > has 3 minutes finalize. It won't hurt by itself as it's enough time to be
> > finalized. But as soon as you have additional object with finalized
> method
> > defined (say, Statement), even empty, all this objects can't be freed
> during
> > this 3 minutes run and you will get OOM. And you will rarely blame your
> > custom object. The best check that can be done to show real reason is to
> > check Finalizer object stack with jstack. I did often see cases when
> custom
> > finalize method is fast, but is synchronized by some heavy-used
> resource.
> >
> > Best regards, Vitalii Tymchyshyn
>
>
> Just for kicks why don't you remove the finalize method recompile the
> JDBC jar and try it.
>
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>