Re: driver initialization and connection separation

On Sun, 31 Jan 2010, Oliver Jowett wrote:
> > 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.
>
> Driver initialization has nothing to do with this; you are making
> assumptions about Class.forName() that are not correct. It does not
> "initialize" the driver in any way other than what the JVM requires for
> any other class (see below)

I'm happy to conceed to your points on "initialization."

> If you get a different sort of SSL-vs-not-SSL connection for the same
> connection URL depending on what connections you got in the past - that
> *is* a bug. Do you have a testcase showing the problem?

Well, that's basically it: Connect with any Postgres JDBC valid URL you
like as many times as you like and it always works perfectly so long as
that URL doesn't ask for SSL, but once you have connected using SSL, the
driver will thereafter ONLY connect with SSL whether the URL asks for it
or not. IF the URL happens to want an SSL connection, it'll work, even if
it's to a different server. Or, at least, so showed my testing last night.

However, I think I just figured it out: Even though it's been in
production for literally a dozen years, I think I just found a bug with
our URL processing code that no one had reported. We're using URL
templates so we can handle everybody's URL format with ease. The ones for
Postgres look like this:

jdbc:postgresql://%h:%p/%d
jdbc:postgresql://%h:%p/%d?%o
jdbc:postgresql://%h:%p/%d?user=%u&password=%pw
jdbc:postgresql://%h:%p/%d?user=%u&password=%pw&%o

where %h is the host
%p is the port
%u is the username
%pw is the password
and %o is the optional keyword=value[&keyword=value] string.

...I think what's happening is that the value that gets substituted for %o
isn't being cleared when it evaluates the new connection data; if there
was no "optional" information to add to the URL for the new connection,
it's retaining its old value. This would explain what I saw and not be an
issue with Postgres at all, obviously!

I've got some work to do to prove the point, and I've got the flu, so I'll
probably leave it until tomorrow. However, it fits the observed
behavior... I should have proved the point before opening my big yap! I'll
blame that social gaff on the flu! -wink-

Thanks for your patience,
Richard