From: | "Heiko W(dot) Rupp" <hwr(at)pilhuhn(dot)de> |
---|---|
To: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
Cc: | Dave Cramer <pg(at)fastcrypt(dot)com>, Vitalii Tymchyshyn <vit(at)tym(dot)im>, PG-JDBC Mailing List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Remove usage of finalizers ? |
Date: | 2013-10-23 06:05:04 |
Message-ID: | 7C3C5273-02BF-4955-A834-3350A8ABC480@pilhuhn.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Am 23.10.2013 um 02:12 schrieb Tom Dunstan:
> and create subclasses of the various concrete statement classes which
> could be used when a debug flag is switched on. e.g.
> DebugJdbc3Statement, DebugJdbc3PreparedStatement,
While this could be beneficial from the "one jar to rule them all"
standpoint, I think this is too much hassle.
> IMO tracing non-closed statement leaks is probably better done in a
> connection pool or jdbc debugging library anyway, so maybe we
> shouldn't bother and just remove it.
Yep.
I think we could just have two jars
psql-debug.jar -- provide very loud logging if Statements and Connections
are not explicitly closed, which can be used for development and debugging.
psql-prod.jar -- without finalize() calls for integration, performance testing and
production
> One question is this, though: how many users out there aren't closing
> their statements currently and are relying, accidentally or
> deliberately, on the current behaviour?
Deliberately relying on the current behavior is just bogus and I guess
no one will know if they accidentally rely on it :-)
Besides that: tools like Findbugs or IntelliJ IDEA warn you when Statements
are not closed as they consider that a leak.
--
Heiko Rupp hwr(at)pilhuhn(dot)de
Blog: http://pilhuhn.blogspot.com @pilhuhn
From | Date | Subject | |
---|---|---|---|
Next Message | Vitalii Tymchyshyn | 2013-10-23 07:06:03 | Re: Remove usage of finalizers ? |
Previous Message | Heiko W. Rupp | 2013-10-23 05:58:57 | Re: Remove usage of finalizers ? |