title: Tomcat 6 connection pool goes wacky when CMS GC is used
body: <p>We recently changed to the CMS garbage collector on our server (<code>XX:+UseConcMarkSweepGC</code>) which worked fine in tests. When we went to production, things were OK for the first few hours, but then we suddenly began to see the dreaded:</p>
  
  <pre><code>org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a connection,
  pool error Timeout waiting for idle object
  </code></pre>
  
  <p>We have seen these messages when the database is physically down or heavily loaded, but this wasn't the case this time. So I began wondering if the recent GC change might be the culprit.</p>
  
  <p>What I don't understand is why we haven't seen this before. Would the change of GC to concurrent-mark-sweep change something (finalizers, perhaps) that would expose problems with this configuration?</p>
  
  <p>My <code>context.xml</code> params look something like this:</p>
  
  <pre><code>&lt;Resource name="jdbc/DB" auth="Container" type="javax.sql.DataSource"
             maxActive="64" maxIdle="60" maxWait="10000"
              defaultAutoCommit="false"
  </code></pre>
  
  <p>I read <a href="http://www.tomcatexpert.com/blog/2010/04/01/configuring-jdbc-pool-high-concurrency" rel="nofollow">this link</a> and began wondering if these were incredibly naive parameters. From my understanding, above 60 connections we will start opening and closing connections without returning them to the pool. But I don't still understand if there is a connection between this and our GC change.</p>
  
  <p>We're using Tomcat 6.0.29 with the MySQL 5.1.45 (5.1.12 JDBC connector).</p>