Blocking on DBCP connection pool (open and close connection). Is database connection pooling in OpenEJB pluggable?

We use OpenEJB on Tomcat (used to run on JBoss, Weblogic, etc.). While running load tests we experience significant performance problems with handling JMS messages (queues). Problem was localized to blocking on database connection pool getting or releasing connection 开发者_如何转开发to the pool. Blocking prevented concurrent MDB instances (threads) from running hence performance suffered 10-fold and worse. The same code used to run on application servers (with their respective connection pool implementations) with no blocking at all.

Example of thread blocked:

Name: JMS Resource Adapter-worker-23
State: BLOCKED on org.apache.commons.pool.impl.GenericObjectPool@1ea6b4a owned by: JMS Resource Adapter-worker-19
Total blocked: 18,426  Total waited: 0

Stack trace: 
org.apache.commons.pool.impl.GenericObjectPool.returnObject(GenericObjectPool.java:916)
org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:91)
   - locked org.apache.commons.dbcp.PoolableConnection@1bcba8
org.apache.commons.dbcp.managed.ManagedConnection.close(ManagedConnection.java:147)
com.xxxxx.persistence.DbHelper.closeConnection(DbHelper.java:290)
....

Couple of questions.

1. I am almost certain that some transactional attributes and properties contribute to this blocking, but MDBs are defined as non-transactional (we use both annotations and ejb-jar.xml). Some EJBs do use container-managed transactions though (and we can observe blocking there as well). Are there any DBCP configurations that may fix blocking?
2. Is DBCP connection pool implementation replaceable in OpenEJB? How easy (difficult) to replace it with another library?

Just in case this is how we define data source in OpenEJB (openejb.xml):

<Resource id="MyDataSource" type="DataSource">
  JdbcDriver oracle.jdbc.driver.OracleDriver
  JdbcUrl ${oracle.jdbc}
  UserName ${oracle.user}
  Password ${oracle.password}
  JtaManaged true
  InitialSize 5
  MaxActive 30
  ValidationQuery SELECT 1 FROM DUAL
  TestOnBorrow true
</Resource>

---

My 2 cts...

1 - Are there any DBCP configurations that may fix blocking?

Although I cannot see it in the doc, I think there should also be a setting attribute named 'WhenExaustedAction' in the Resource node that could take a value "GROW" (value 2) as opposed to "BLOCK" (value 1) or "FAIL" (value 0). This comes straight from the Pools common. Both Hibernate and Cayenne do use this DBCP setting. Don't know about OpenEJB though.

No need to say that this would work only if all connections are dutifully closed of course (which is sometimes hard to guarantee). Then you could probably see through JMX how many connections you need at peak activity time and you could then set the maxActive to a higher value evolved from these measures.

2 - Is DBCP connection pool implementation replaceable in OpenEJB? How easy (difficult) to replace it with another library?

Sorry no idea. Would imagine yes. Or possibly DBCP allows another connection pool manager.

UPDATE: Just had a look in the code and it seems DBCP is the only option for connection pooling.

Incidentally I've seen that the whenExhaustedAction settings. is not supported by openejb.xml.
There would however, still be one option left, since you are using an Oracle Database.
One thing you could try is to use Oracle implicit connection caching (assuming version 10g) and leave DBCP with an arbitrary "sufficient" amount of connections. To do so, you would need to configure in the openejb.xml resource block, ConnectionProperties properties and use Oracle JDBC connection properties. That is connectionCachingEnabled=true and at least connectionCacheName and connectionCacheProperties. In this way I would lure DBCP into believing it's doing the real job and actually using Oracle's pooling mechanism. That would also mean taking little risks with DBCP and thereby a more liberal sizing of the maxActive setting.

---

Resolved issue with dbcp blocking by changing pool configuration (openejb.xml):

TestOnBorrow false

Thank you, Andy, from OpenEJB team!