On Wed, Feb 15, 2012 at 6:30 AM, Vitalii Tymchyshyn <tivv00@gmail.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
