Question

I have the following code in my services.xml

<bean id="executorService" class="java.util.concurrent.Executors" factory-method="newFixedThreadPool">
    <constructor-arg value="10" />
</bean>
<task:annotation-driven executor="executor" />

<task:executor id="executor" pool-size="10" queue-capacity="100" rejection-policy="CALLER_RUNS" />

In the same project, I also have connections to the database, that use dbcp.BasicDataSource.

I’ve read that DBCP is effective mostly when your app is single-threaded, NOT multi-threaded. The use of executor tells me that the app is multi-threaded. Do you think the use of DBCP here is not proper? Would this be a good practice? Or, am i living an age-old myth that DBCP can’t handle multi-hreaded environment?

Any guidance in the right direction would be appreciated.

Answer 1

I’ve read that DBCP is effective mostly when your app is single-threaded, NOT multi-threaded.

Can you provide source of this information? The only issue with DBCP is that it uses single lock to synchronize all operations on a pool, which may become a bottleneck in heavy multi-threaded applications.

DBCP can’t handle multi-threaded environment?

Think about it. If your application is only single-threaded, it will never user more than one connection. JDBC is blocking so you can’t use two connections at once from the same thread (simplifying). That being said, if you only query database from one thread, not only you don’t need a connection pool, you don’t need a DataSource. One Connection is enough.

So… we are using connection pools mostly in multi-threaded applications especially where number of threads is much larger than number of available connections and threads are competing between each other. Every sane connection pool is capable of working in multi-threaded environment.