Tomcat: DBCP is Single Threaded

Question

While looking to upgrade to tomcat7, I understand the connection pool is a major improvement. I read that commons-dbcp is single threaded, in order to be thread safe commons-dbcp locks the entire pool, even during query validation.

So as I understand, the connection pool will be locked when handing out new connections and other threads which need connections from the pool will wait until they are handed their respective connection?

Is my understanding right?

Answer 1

While looking to upgrade to tomcat7, i understand the connection pool is a major improvement. I read that commons-dbcp is single threaded, in order to be thread safe commons-dbcp locks the entire pool, even during query validation.

Where did you read that? While it might have been true of earlier DBCP releases I'm fairly sure it is not true for current releases.

So as i understand, the connection pool will be locked when handing out new connections and other threads which need connections from the pool will wait until they are handed their respective connection?

There are brief periods of locking but they do no last the entire of the borrow() and the return() methods.

There is contention during borrow() and return() but you'll only notice it on multi-core systems the borrow() / return() at high rates.

Tomcat 7 ships with jdbc-pool that does not have this contention.

DBCP2 also does not have this contention and is used (in snapshot form as there has not yet been an official release) in Tomcat 8 onwards.

Is my understanding right

The best way to understand exactly what is locked and when is to look at the source.

Comments

http://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html#Introduction
http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Introduction

Bullet-point #1 in both cases.

Answer 2

That is correct. This is because the checkout method is implemented like this (ignore syntax issues, this is psuedocode, won't match method signatures, etc.):

public synchronized Connection checkout()
{
 // obtain connection by whatever means necessary,
 // validate the connection, etc.
}

There's nothing particularly awkward, stupid or evil about the above code. It's just that it uses "synchronized" for the whole method and there are some performance penalties for doing that.

The term "single-threaded" is a bit misleading... of course DBCP is thread-safe and multiple threads can access it, but there is serialized access to the checkout method.

Tomcat-pool uses a different strategy for thread-safety that lends itself to better performance under heavier loads.