Hi. There are two issues here:
1) Perhaps you don't like where the messages are going, i.e. to Tomcat console. If this is the issue, upgrade to c3p0-0.9.0-pre5, which will log to log4j or jdk14logging.
2) Perhaps you don't like that Exceptions keep occuring in your application. Though I don't know for sure (and including more config information in your question would have helped), here is what I think is going on: Your pool, for whatever reason, decides to close and discard a Connection. The Connection has cached Statements associated with it. At Connection close, tasks are posted nearly simultaneously to asynchronously close all cached Statements belonging to the Connection as well as the Connection itself. BUT, some drivers are a bit buggy, and can't handle the unusual ordering where a Connection and its child Statement are closed simultaneously, or in an unusual order. When a Statement tries to close() after its parent Connection has already closed, your JDBC driver throws a NullPointerException. (Oracle seems also to have a problem -- an occasional deadlock -- with the simultaneous close of a Connection and its child Statements.
I've implemented a change in the Statement pooling to ensure all cached Statements close prior to the call to Connection close(), which should resolve these problems. This change isn't yet in any public release, because I'd like to test it a bit more. If you'd like to try a development version with the change, write me directly (
swaldman@mchange.com), and I'll send you a development snapshot, which should, if I'm right about the problem, prevent these Exceptions from occurring at all.
smiles,
Steve (c3p0 guy)
Login
FAQ
Search
