driver initialization and connection separation - Mailing list pgsql-jdbc
From | Richard Troy |
---|---|
Subject | driver initialization and connection separation |
Date | |
Msg-id | Pine.LNX.4.33.1001301513270.6187-100000@denzel.in Whole thread Raw |
Responses |
Re: driver initialization and connection separation
|
List | pgsql-jdbc |
Hello All, I've got a Java based application that started life way back in Java 1.0. It supports about 6 RDBMS engines, presently, including Postgres, of course... When it needs to have multiple RDBMS connections, as it occasionally does, it merely creates an instance of itself and calls itself. This lets it connect to as many database instances as it likes and never confuse or otherwise conflate them as the instances connect to various RDBMSes. (For the curious, the API the application is coded against does sql dialect translation on-the-fly, sophisticated error handling, such as losing a network connection to an RDBMS, client-side, RDBMS independent journaling, etc. and this is why new instances, though seemingly a bit 'heavy-weight' is in fact a good, clean solution.) However, I haven't ever previously asked it to use the embeded SSL features before and this seems to present a problem - maybe more than one problem! I plan on eventually connecting a Postgres instance to the wilds of the internet. There is no need to validate users via certificates, though that's a cool thing to do that we'll eventually get to, and in fact forcing client authentication would be a real show-stopper at this point. So I was pleased to see the NonValidating Factory feature. I got the connectivity working just fine, thank you, but when I then asked the application to switch between encrypted and non-encrypted connections, it "broke." A modest amount of testing showed that when the app. attempted to reload the driver, the Postgres JDBC driver wasn't initializing as outlined here: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html#forName%28java.lang.String%29 I would have taken "initialization" to mean removing components (like NonValidatingFactory and WrappedFactory). Please note that the applciation did not call deregisterDriver as outlined here: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/DriverManager.html#deregisterDriver%28java.sql.Driver%29 Rather, the app. just calls Class.forName() as it typically would in making a connection. ...Driver initialization has never before been an issue, so I'd never even considered that anything else was necessary. My supposition is that because the driver already found itself loaded, it just left itself in place. I'm considering what to do about this; On the one hand, to my mind this would be considered a bug, but on the other, it might be deemed that the proper thing to do to deregister the driver - deregistering wouldn't be a work-around, per se. (I'm assuming that de-registering the driver works to solve this problem!) Still, what, then, would "initialize" mean, as describe above, if not to clear out issues like this? I was also thinking about the same issue for the "WrappedFactory", which I'm not presently using but well might. Because the application creates multiple instances for multiple connections, I presume existing connections are safe from disruption by loading an incompatible driver setup - if anyone knows otherwise, please comment! I'm thinking that the driver instances will be unique to each instance of my class that calls them, but at least I know I am making an assumption. Meanwhile, I'm off to see if in fact deregistering the driver works... Thanks for your thoughts. Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-717-6942 rtroy@ScienceTools.com, http://ScienceTools.com/
pgsql-jdbc by date: