解决[c3p0] A PooledConnection that has already signalled a Connection error is still in use

1.[c3p0] A PooledConnection that has already signalled a Connection error is still in use

You have to use either Transaction.commit even if you are only doing a select.

2.可以使用的参数，除了连接串以外

  <!-- See c3p0's docs for more info. -->


  <!-- <attribute name="AcquireIncrement">3</attribute> -->


  <!-- <attribute name="AcquireRetryAttempts">30</attribute> -->


  <!-- <attribute name="AcquireRetryDelay">1000</attribute> -->


  <!-- <attribute name="AutoCommitOnClose">false</attribute> -->


  <!-- <attribute name="AutomaticTestTable"></attribute> -->


  <!-- <attribute name="BreakAfterAcquireFailure">false</attribute> -->


  <!-- <attribute name="CheckoutTimeout">0</attribute> -->


  <!-- <attribute name="ConnectionTesterClassName">0</attribute> -->


  <!-- <attribute name="Description">A pooled c3p0 DataSource</attribute> -->


  <!-- <attribute name="FactoryClassLocation"></attribute> -->


  <!-- <attribute name="ForceIgnoreUnresolvedTransactions">true</attribute> -->


  <!-- <attribute name="IdleConnectionTestPeriod">-1</attribute> -->


  <!-- <attribute name="InitialPoolSize">3</attribute> -->


  <!-- <attribute name="MaxIdleTime">0</attribute> -->


  <!-- <attribute name="MaxPoolSize">15</attribute> -->


  <!-- <attribute name="MaxStatements">0</attribute> -->


  <!-- <attribute name="MaxStatementsPerConnection">0</attribute> -->


  <!-- <attribute name="MinPoolSize">0</attribute> -->


  <!-- <attribute name="NumHelperThreads">3</attribute> -->


  <!-- <attribute name="PreferredTestQuery"></attribute> -->


  <!-- <attribute name="TestConnectionOnCheckin">false</attribute> -->


  <!-- <attribute name="TestConnectionOnCheckout">false</attribute> -->


  <!-- <attribute name="UsesTraditionalReflectiveProxies">false</attribute> -->

3. Configuring Connection Testing

c3p0 can be configured to test the Connections that it pools in a variety of ways, to minimize the likelihood that your application will see broken or "stale" Connections. Pooled Connections can go bad for a variety of reasons -- some JDBC drivers intentionally "time-out" long-lasting database Connections; back-end databases or networks sometimes go down "stranding" pooled Connections; and Connections can simply become corrupted over time and use due to resource leaks, driver bugs, or other causes.

c3p0 provides users a great deal of flexibility in testing Connections, via the following configuration parameters:

• automaticTestTable
• connectionTesterClassName
• idleConnectionTestPeriod
• preferredTestQuery
• testConnectionOnCheckin
• testConnectionOnCheckout

idleConnectionTestPeriod , testConnectionOnCheckout , and testConnectionOnCheckin control when Connections will be tested. automaticTestTable , connectionTesterClassName , and preferredTestQuery control how they will be tested.

When configuring Connection testing, first try to minimize the cost of each test. By default, Connections are tested by calling the getTables() method on a Connection's associated DatabaseMetaData object. This has the advantage of working with any database, and regardless of the database schema. However, empirically a DatabaseMetaData.getTables() call is often much slower than a simple database query.

The most convenient way to speed up Connection testing is to define the parameter automaticTestTable . Using the name you provide, c3p0 will create an empty table, and make a simple query against it to test the database. Alternatively, if your database schema is fixed prior to your application's use of the database, you can simply define a test query with the preferredTestQuery parameter. Be careful, however. Setting preferredTestQuery will lead to errors as Connection tests fail if the query target table does not exist in your database table prior to initialization of your DataSource .

Advanced users may define any kind of Connection testing they wish, by implementing a ConnectionTester and supplying the fully qualified name of the class as connectionTesterClassName . If you'd like your custom ConnectionTesters to honor and support the preferredTestQuery and automaticTestTable parameters, implement UnifiedConnectionTester , most conveniently by extending AbstractConnectionTester . See the api docs for more information.

The most reliable time to test Connections is on check-out. But this is also the most costly choice from a client-performance perspective. Most applications should work quite reliably using a combination of idleConnectionTestPeriod and testConnectionsOnCheckIn . Both the idle test and the check-in test are performed asynchronously, which leads to better performance, both perceived and actual.

Note that for many applications, high performance is more important than the risk of an occasional database exception.

In its default configuration, c3p0 does no Connection testing at all. Setting a fairly long 
idleConnectionTestPeriod
, and not testing on checkout and check-in at all is an excellent, high-performance

approach.


...

idleConnectionTestPeriod

Default: 0

If this is a number greater than 0, c3p0 will test all idle, pooled but unchecked-out connections, every this number of seconds. [See "Configuring Connection Testing" ]

参考：

http://www.djvoo.net/d/jboss:C3P0

http://www.mchange.com/projects/c3p0/index.html#configuring_connection_testing