Hi,

i'm using C3P0 as connection-pool for a Tomcat/Struts/Oracle App

The connection-pool config:



The Oracle/JDBC config:



When i'm doing some load-test, after a while i'm getting those exceptions:


and




All connections are closed with try/catch/finally like in the tomcat docs described. I'm quite sure that those exceptions aren't caused by c3p0, but any help how to solve this problem is very appreciated.

Thanks in advance!

Hi... Two things:

1) The first exception you're seeing aren't necessarily a problem, if it's infrequent. The pool is doing a Connection test on checkout, as you've configured, and it's failing. You test Connections because they sometime do fail.

2) It looks like you're using an older version of c3p0, and the second stack trace could be related to some bugs in older versions whereby Connections were prematurely closed following certain failures and exceptions. Please upgrade, if possible, to c3p0-0.9.0-pre6, which I hope is near release quality. (I say "I hope" because I could use some more feedback, hint, hint!)

Newer versions of c3p0 are drop-in replacements for older versions. Just download the binary release from http://sourceforge.net/projects/c3p0, and replace the old jar file with the new one. And please let me know how it works for you!

Steve
(c3p0 guy)

Hi, thanks for the detailed answer.

I switched to c3p0-0.9.0-pre6 here is my config:




After doing two load test the following exceptions occured:



This exception only occurred once in many test-runs.


java.sql.SQLException: Connection is invalid

Occurred one time only too. Before swichting to c3p0-0.9.0-pre6 this exception was thrown quite frequently.

java.sql.SQLException: E/A-Exception: Socket closed

Stills occurrs very frequent, but only at one point of the application were long running queries are executed. No other sql-statements are affected, only one line of code. There are about 15 points in the application were sql is executed but only one point were the E/A Exception is thrown. I have checked all statements if they are closed with try/catch/finally several times. I can't tell how many sql-statements are executed in a test-run, but certainly several hundreds in about 3 minutes.

Blunted,

The InterruptedException is probably not a problem. It looks like when you considered your test done, you closed the DataSource, but a client was still waiting for a Connection. I'll modify the pool to be a bit less verbose in this expected case.

Also, as before, the "java.sql.SQLException: Connection is invalid", if it's the same as the one you showed before, probably just indicates that a Connection test failed, so the Connection has been discarded. This is a normal occurence, so long as its infrequent. (Does the Exception show more stack trace -- a root cause Exception -- with c3p0-0.9.0-pre6?)

The "java.sql.SQLException: E/A-Exception: Socket closed" is potentially a problem. I can't tell you why it's occuring; it's Oracle's driver that is throwing it. Here is one idea: Since this is a load test, there are probably lots of threads working concurrently. Make sure that while some threads are executing this SQL via a Statement, no other threads might somehow close() the Statement, it's parent Connection, or its parent pool. If, for example, your test periodically closes or destroys the ComboPooledDataSources it creates [using close( true ) or DataSources.forceDestroy( ... )], active Connections could be closed, and active queries interrupted. This could occur in any query, but if one query takes substantially longer than others, you would see it most frequently there. (It could be a similar issue to the InterruptedException -- perhaps when your test decides it's over, there are still active threads, and sometimes when you shut things down, these threads are in the middle of things and throw Exceptions.)

smiles,
Steve

At the risk of stealing someone elses thread I get the following when I shut down my session factory. Is this normal?

mr. swaldman thanks for helping!

The "java.sql.SQLException: E/A-Exception: Socket closed" Exception
was caused by an error in the app.
Threads which were waiting for queries have been interrupted.

Everything is running fine now.
In about a hour we started about 9000 small (4 lines and 24 rows resultset) and 160 large (5527 lines and 241 rows) datawarehouse queries and transfered them to html. No connection was lost or broken. Every query was finished.

Blunted -- You are very welcome, and I'm glad things are working for you!

gstamp -- Please try c3p0-0.9.0-pre6; I'm pretty sure it will fix this. The issue is that when closing Connections with pooled Statements, the pooled Statements and the parent Connection were closed asynchronously. That means that sometimes the parent Connection would close before or simultaneous to child Statements closing. Several drivers do not handle this well, throwing NullPointerExceptions, or in the case of Oracle, sometimes deadlocking. c3p0-0.9.0-pre6 is modified to ensure that all child Statements close before Connection close is called. Good luck!

Blunted -- You're using a very old version of jTDS; you should be thinking about upgrading it. Newer versions don't exhibit this behavior, for example.

Steve -- As far as I can tell the error was occuring because two different threads were closing the Statement at the same time. This could indeed happen if the Statement and its Connection were closed at the same time.

Alin,
The jTDS Project.

alin_sinpalean -- I don't think, that i jTDS. Why do you think, that i'm using it, maybe you mixed something up?

Blunted, you're right. Sorry for the confusion, my post was for gstamp. This is why hijacking posts is not a good idea. :o(

Alin.