Re: Unregistering the driver from DriverManager

I have no objection to an unregister static method being added. It's not in
the API so it would not effect anything really

Dave Cramer

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

On 29 December 2014 at 04:53, Christopher BROWN <brown(at)reflexe(dot)fr> wrote:

> Hello,
>
> I'm starting to integrate the Postgresql JDBC driver into an OSGi
> environment, as an OSGi bundle. I'm evaluating the different ways to avoid
> a classloader leak with DriverManager when hot-swapping the driver bundle
> without restarting the host application, and am seeking suggestions on best
> practice regarding the Postgresql JDBC driver.
>
> Another bundle (which I provide, it's not third-party) will directly
> depend upon it (loading classes directly, namely org.postgresql.Driver);
> when the Postgresql JDBC driver classes are loaded, the other bundle will
> create a DataSource using a JDBC connection pool, and register the
> DataSource as an OSGi service. Normally, that's all that will happen
> during the application lifecycle, but in principle, it's possible for the
> administrator to want to replace say the 9.3 driver with the 9.4 driver by
> removing the 9.3 ".jar" at runtime, and replacing it with the 9.4 ".jar",
> all at runtime; when the first ".jar" is deleted, the dependent bundle is
> knocked offline, unregistering the DataSource automatically, and notifying
> all clients; when the second is installed, the application is once again
> fully-functional (and all this normally occurs within a few hundred
> milliseconds).
>
> Looking at the source code, I can see that the org.postgresql.Driver class
> registers itself in a "static" block with DriverManager (which is the
> correct behavior regarding the JDBC spec). However, short of a brute-force
> loop -- like this one: http://stackoverflow.com/a/5315467 (enhanced to
> check the class name of each driver, to avoid clobbering unrelated driver
> registrations) -- is there any other approach possible or that could be
> added, say a NonRegisteringDriver (superclass of Driver, with all logic
> except for the static initializer) or an "unregister()" static method, or a
> field containing the registered Driver instance?
>
> Thanks,
> Christopher
>
>