top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Tomcat: DBCP is Single Threaded

+2 votes
370 views

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?

posted Nov 7, 2013 by Deepak Dasgupta

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

+1 vote

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.

answer Nov 7, 2013 by Sanketi Garg
+1 vote

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.

answer Nov 7, 2013 by Jagan Mishra
Similar Questions
+1 vote

In tomcat does the no . of open sockets on http port (netstat -anlp|grep 8080) is it equal to number of threads in use in tomcat .
Actually I want to understand how & when I can say that the all threads in a tomcat are fully utilized that why it is responding slow.

+2 votes

There is this native Apache API if I recall correctly to speed up Apache. Is there such for Tomcat too?
And should this be established at any rate for production servers?

+2 votes

I installed apache-tomcat-7.0.47 on debian and also installed and configured railo 4.1.1.009. I added the servlet for CFML and now i ended up with lots of WEB-INF directories in my tomcat directory and the subdirectories.

A find gives me the following output :

./lib/WEB-INF
./bin/WEB-INF
./work/WEB-INF
./logs/WEB-INF
./temp/WEB-INF
./conf/WEB-INF
./default/examples/WEB-INF
./default/WEB-INF
./default/manager/WEB-INF
./default/host-manager/WEB-INF
./default/ROOT/WEB-INF
./default/docs/appdev/sample/web/WEB-INF
./default/docs/WEB-INF
./webapps/WEB-INF
./webapps/ROOT/WEB-INF

The tomcat takes quite a while (350s) to start up and this is really starting to annoy me. So, whats this and what are some common settings to achieve a faster start up of the tomcat?

...