driver initialization and connection separation

Поиск
Список
Период
Сортировка
От Richard Troy
Тема driver initialization and connection separation
Дата
Msg-id Pine.LNX.4.33.1001301513270.6187-100000@denzel.in
обсуждение исходный текст
Ответы Re: driver initialization and connection separation  (Oliver Jowett <oliver@opencloud.com>)
Список 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 по дате отправления:

Предыдущее
От: Sven Hafner
Дата:
Сообщение: Re: Is there a schema parameter for the jdbc URL ?
Следующее
От: Oliver Jowett
Дата:
Сообщение: Re: driver initialization and connection separation