Re: driver initialization and connection separation

On Sun, 31 Jan 2010, Oliver Jowett wrote:
>
> Richard Troy wrote:
>
> > 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."
>
> What were you trying to do exactly, and how did it break?

Sorry Oliver, I meant to be clear.

The application can connect to any RDBMS, Postgres, Oracle, Ingres,
whatever, and reconnect to any other, whenever the user wants. But once it
has connected to Postgres using the SSL feature, all future connections
using Postgres will use SSL. The only solution thus far is to kill the
application and then start it again - there is no switching between using
SSL and not using SSL, even though the driver is officially reloaded using
Class.forName(driverClassName).

Note that the official Java documentation from Sun says that doing so is
equivalent to Class.forName(className, true, currentLoader) which is using
the method for.Name(name, initialize, ClassLoader) - I cited a URL to
their site to support this.

To me this says that subsequent executions of Class.forName("driver")
should yield identical results as with the first time it's executed, but
that's demonstrably not true with Postgres - it "remembers" that it was
asked to use SSL in the past and it continues to want to do so in the
future.

It seems to me that there's something missing from the initialization
code, namely to remove the SSL features if the driver was already loaded.
It should only be loaded when a URL asking for it comes along with the
option ssl=true (for example). However, one could easily argue that it's
not the initialization code that needs help but the code that constructs a
new connection; it makes just as much sense that the request for a new
connection give the appropriate type of connection, with or without SSL
depending on whether the option in the URL was specified.

...I readily admit I haven't tried making multiple, simultaneous
connections from the same instance of the driver; I presume that's
possible but I've never needed. It seems to me this is
much more a question of each individual connection than the driver itself.

...Your follow-on comment (below) about classes being initialized only
once isn't helpful here because it isn't clear to me whether this is a
case of initializing an object or loading _code_ that instantiates
objects. In other words, even though I've been using Java since it's first
release, I've never before had to worry about the code that instantiates
objects changing while my code is running, so I haven't thought about it
much. To my mind, each instance of my objects which then instantiate other
objects - like JDBC connection objects - should get clean, separate and
distinct objects, so in effect the driver code is loaded multiple times.
But as I said, I could be wrong - I don't know much about how the JVM
manages code that's loaded, but my suspicion is that it'll manage the
individual instances of loading the same driver separately.

Meanwhile, I just added this bit of code prior to the call to
Class.forName():

for (Enumeration fu = DriverManager.getDrivers(); fu.hasMoreElements();)
{
DriverManager.deregisterDriver((java.sql.Driver)fu.nextElement());
}

As I said, I don't have to worry about multiple connections within a
single instance of this class, so deregistering all the drivers is fine -
there should only ever be one connection and we're about to replace it. If
there's an unacceptable performance hit for unloading a driver when it
isn't needed, then I'll think about adding to this. But if it works, it's
staying! -smile- I'll probably test it in the next few minutes...

Regards,
Richard

>
> > 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
>
> Well, classes only ever get initialized once.
>
> -O
>

--
Richard Troy, Chief Scientist
Science Tools Corporation
510-717-6942
rtroy(at)ScienceTools(dot)com, http://ScienceTools.com/