we had the problem you describe as well.
I thought it was a bug in the dbcp common classes, so I decompiled them and changed the source which fixed it.
However apparently that was not the way to go, since it is caused by a bug in the oracle driver.
I posted my original emails concerning this topic below, hope it helps you.
Since it only occurred on some systems I worked on, I gathered it indeed was a bug in my oracle driver which led me to believe there are different versions of the classes12.jar (zip whatever), and that there was no problem in the commons lib, so I haven't filed any bug report.
What follows is a reply to an email to me also found below.
If there are people who think this should be entered into bugzilla, let me know, I'll do my best.
To: Hans <[EMAIL PROTECTED]> Subject: Re: NullPointer with Oracle 9 driver using commons-dbcp
Hi Hans,
Issue 17301 was fixed in the oracle driver and not in dbcp.
Currently DBCP allows a second close() on statement & resultset to be handeled by the database driver. (A second close on connection is blocked by DBCP)
If the oracle driver has a problem with a second close on resultset level then the driver should be fixed.
Of course DBCP can implement a workaround but then it should be done for both (statement & resultset).
I'm not against this change in DBCP but it should be documented (in a bugzilla item and properly tested with JUnit tests.
Things like this can always be discussed on the commons-dev mailing list if you are unsure about the process of getting your fix included.
In short:
First make a new Bugzilla issue for it. Include a small testcase to reproduce the error, the resulting stacktrace and the fix you mailed to me. I always make a bugzilla entry for each change (makes it easy to create the release notes later on)
Thanks for reporting this problem.
Regards Dirk
Hans wrote:
Hi Dirk,
I am not familiar with how the process goes, but I downloaded last nights nightly build for the commons-dbcp, in order to profit from the bugfix 17301.
The problem still persisted, only now it occurs in DelegatingResultSet instead of DelegatingStatement ( * @version $Revision: 1.13 $ $Date: 2004/03/06 13:35:31 $
).
I can fix it by changing:
public void close() throws SQLException {
try {
if(_stmt != null) {
((AbandonedTrace)_stmt).removeTrace(this);
_stmt = null;
}
try {
if (_res != null) _res.close();
} catch (Exception e) {//ignore
};
}
catch (SQLException e) {
handleException(e);
}
}
to
public void close() throws SQLException {
if(_stmt != null) {
((AbandonedTrace)_stmt).removeTrace(this);
_stmt = null;
}
try {
if (_res != null) {
_res.close();
_res == null;
}
} catch (Exception e) {//ignore
e.printStackTrace();
};
}
I don't if I should even be sending this report since it concerns a nightly build, but I'd like to learn.
Kind regards,
Hans
grtz Hans
At 14:09 11/06/2004 -0700, you wrote:
I also have 1 problem related the database connection which needs help. I used to have the infamous No suitable driver error, but after I corrected my connect string by adding schema into it (defined in context.html), it works for me:
<parameter> <name>url</name> <value>jdbc:oracle:thin:<schema>@<server>:<port>:<sid></value> </parameter>
After this, Tomcat has no problem to locate the driver, and I got a valid DataSource back via JNDI lookup. However, when I tried to use DataSource to getConnection, I got the following error: (part of the stack trace)
init exception: java.lang.NullPointerException java.lang.NullPointerException at org.apache.commons.dbcp.DelegatingConnection.close(DelegatingConnecti on.java:195) at org.apache.commons.dbcp.PoolableConnection.reallyClose(PoolableConnec tion.java:129) at org.apache.commons.dbcp.PoolableConnectionFactory.destroyObject(Poola bleConnectionFactory.java:311) at org.apache.commons.dbcp.BasicDataSource.validateConnectionFactory(Bas icDataSource.java:842) at org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSou rce.java:821) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource .java:532)
I have no idea where the Null Pointer Exception came from, and the DataSource I got back from server is not null either. I posted this problem before but no one answered. Now I write a class just to load the driver and get the database pool by myself, and it works! But I still want to have the database pooling functionalities be handled by Tomcat, and I really want to know what goes wrong after all! Just hope to post this problem to this thread can get some feedback! Thanks in advance for any input!
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 11, 2004 1:28 PM To: [EMAIL PROTECTED] Subject: Re: Database connection problems after redeploying war
We've got the exact same issue in our environment at all. Every time we define a datasource, we have to restart Tomcat so that datasource can be accessed. Additionally, when using a traditional web server frontend, like Apache or IIS, with mod_jk or mod_jk2, we have to restart the web server so the mod_jk connector will restart and be able to use the datasources available to the restarted Tomcat. We were hoping using a web server frontend with a mod_jk(2) connector would not require bouncing the web server each time we bounced Tomcat but that's just not the case. :(
Any ideas for solving this would be greatly appreciated.
Peace...
Tom
"Chad Boyd"
<[EMAIL PROTECTED]
.net> To <[EMAIL PROTECTED]>
06/11/2004 12:38 cc PM
Subject Database connection problems after Please respond to redeploying war
"Tomcat Users
List"
<[EMAIL PROTECTED]
rta.apache.org>
I'm having trouble accessing a database connection after war redeployment. I've read the documentation several times and went through suggestions posted in the mailing lists, but nothing has worked. I prefer the approach of having the context.xml file in the META-INF directory in the war itself. When I try this, I get the infamous "Cannot create JDBC driver of class '' for connect URL 'null'" error message. When I put the <context> element back into the server.xml file, everything is fine, except for the fact that I can't redeploy the war file without restarting Tomcat. This is very frustrating and time-consuming. Does anyone know why the context.xml file is not working for me? I've included the contents of this file below. I'm using Tomcat 5.0.19.
Thanks in advance.
Chad
<Context debug="0" docBase="h" path="/h" privileged="false" reloadable="false"> <Logger className="org.apache.catalina.logger.FileLogger" prefix="localhost_h_log." suffix=".txt" timestamp="true"/>
<Resource name="jdbc/myPool" auth="Container" type="javax.sql.DataSource"/>
<ResourceParams name="jdbc/myPool"> <parameter> <name>factory</name> <value>org.apache.commons.dbcp.BasicDataSourceFactory</value> </parameter> <parameter> <name>maxActive</name> <value>100</value> </parameter> <parameter> <name>maxIdle</name> <value>30</value> </parameter> <parameter> <name>maxWait</name> <value>10000</value> </parameter> <parameter> <name>removeAbandoned</name> <value>true</value> </parameter> <parameter> <name>logAbandoned</name> <value>true</value> </parameter> <parameter> <name>username</name> <value>...</value> </parameter> <parameter> <name>password</name> <value>...</value> </parameter> <parameter> <name>driverClassName</name> <value>com.inet.tds.TdsDriver</value> </parameter> <parameter> <name>url</name> <value>...</value> </parameter> </ResourceParams> </Context>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
