RE: [Proxool-developer] Re: Proxool and web apps

[Martin C. <mus...@us...>]

> We are working on another issue at the moment that I don't believe is
> connected with this problem but is so close it would be silly not to
> mention it. The ReloadMonitor uses System Properties to record the class
> load time and Bas has informed me that this is not allowed for a J2EE
> JDBC Driver. We will be coming up with another solution (probably
> writing to file instead) shortly. I don't see how that would help your
> problem, Martin.

Don't quote me on this, but I think the servlet spec says no touching the
Systems Properties from servlet code. I'm almost positive Tomcat sets the
security policy to deny this. A file would be the most logical and friendly
solution, although how and where you put that file without using System
Props is beyond me, I guess another configurable property. Although
seriously, something like proxool belongs in the common or for Tomcat as my
Tomcat administrator pointed out the share directory. All web apps should
share JDBC drivers and Connections.

This link will provide more insight to Tomcat classloader madness:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html


> Agreed. The trick is knowing whether the URL is wrong or if the DB is
> down (assuming that no connections have been built to date). Perhaps
> this would be declared in the exception thrown by the driver? For
> instance, we should be able to spot if no delegate driver was found (the
> URL was so bad we couldn't even find a driver to accept it). After that
> it is probably driver specific - but we could have it configurable, like
> the fatal-sql-exception property.

Hmmm... perhaps I'm being a little naive, I would just try connecting x
number of times and then give-up (the number of times configurable of
course). Only if client code requests a connection specifically again for
the same URL it will try it connection routine. This number of tries
trapping routine would only run if no successful connection has been made to
that URL, otherwise then you let it do your keep-alive routine. Makes sense
(today has been an inarticulate day for me;)?

> Yes, I think that's the answer. The fatal-sql-exception property spots
> *Connections* that are no use anymore. We should also have a
> hopeless-configuration-exception property. We could list suggest values
> for common drivers on the web site. Or possibly, recognise the driver
> and do that automatically (allowing override by configuration).

Trying to support mulitple drivers this way would be a testing and
maintenace nightmare, and makes too many assumptions for the user. I know
JDBC fails for standardise exceptions in the spec which is a real short
coming.

Cheers.
Martin