Controlling database connections - Java-Springs


Spring obtains a connection to the database through a DataSource. A Data Source is part of the JDBC specification and is a generalized connection factory. It allows a container or a framework to hide connection pooling and transaction management issues from the application code. As a developer, you need not know details about how to connect to the database; that is the responsibility of the administrator that sets up the datasource.You most likely fill both roles as you develop and test code, but you do not necessarily have to know how the production data source is configured.

When using Spring's JDBC layer, you obtain a data source from JNDI or you configure your own with a connection pool implementation provided by a third party. Popular implementations are Apache Jakarta Commons DBCP and C3P0. Implementations in the Spring distribution are meant only for testing purposes and do not provide pooling.

You obtain a connection with DriverManagerDataSource as you typically obtain a JDBC connection.Specify the fully qualified classname of the JDBC driver so that the Driver Manager can load the driver class. Next, provide a URL that varies between JDBC drivers.(Consult the documentation for your driver for the correct value.) Then provide a username and a password to connect to the database.

Here is an example of how to configure a DriverManagerDataSource in Java code:

DriverManagerDataSource dataSource = new DriverManagerDataSource();

Here is the corresponding XML configuration:

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="${jdbc.driverClassName}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
<context:property-placeholder location=""/>

The following examples show the basic connectivity and configuration for DBCP and C3P0. To learn about more options that help control the pooling features, see the product documentation for the respective connection pooling implementations.

DBCP configuration:

<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="${jdbc.driverClassName}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
<context:property-placeholder location=""/>

C3P0 configuration:

<bean id="dataSource"
class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
<property name="driverClass" value="${jdbc.driverClassName}"/>
<property name="jdbcUrl" value="${jdbc.url}"/>
<property name="user" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
<context:property-placeholder location=""/>


The Data Source Utils class is a convenient and powerful helper class that provides static methods to obtain connections from JNDI and close connections if necessary. It supports thread-bound connections with, for example, DataSourceTransactionManager.


The Smart Data Source interface should be implemented by classes that can provide a connection to a relational database. It extends the Data Source interface to allow classes using it to query whether the connection should be closed after a given operation. This usage is efficient when you know that you will reuse a connection.


Abstract Data Source is an abstract base class for Spring's Data Source implementations that implements code that is common to all Data Source implementations. You extend the Abstract Data Source class if you are writing your own DataSource implementation.


The Single Connection Data Source class is an implementation of the Smart DataSource interface that wraps a single Connection that is not closed after each use. Obviously, this is not multi-threading capable.

If any client code calls close in the assumption of a pooled connection, as when using persistence tools, set the suppressClose property to true. This setting returns a close-suppressing proxy wrapping the physical connection. Be aware that you will not be able to cast this to a native Oracle Connection or the like anymore.

This is primarily a test class. For example, it enables easy testing of code outside an application server, in conjunction with a simple JNDI environment. In contrast to Driver Manager Data Source, it reuses the same connection all the time, avoiding excessive creation of physical connections.


The Driver Manager Data Source class is an implementation of the standard Data Source interface that configures a plain JDBC driver through bean properties, and returns a new Connection every time.

This implementation is useful for test and stand-alone environments outside of a Java EE container, either as a DataSource bean in a Spring IoC container, or in conjunction with a simple JNDI environment. Pool-assuming Connection.close() calls will simply close the connection, so any Data Source-aware persistence code should work. However, using Java Bean-style connection pools such as commons-dbcp is so easy, even in a test environment, that it is almost always preferable to use such a connection pool over Driver Manager Data Source.


Transaction Aware Data Source Proxy is a proxy for a target Data Source, which wraps that target DataSource to add awareness of Spring-managed transactions. In this respect, it is similar to a transactional JNDI DataSource as provided by a Java EE server.

(See the Transaction Aware Data Source Proxy Javadocs for more details.)

Data Source Transaction Manager

The Data Source Transaction Manager class is a Platform TransactionM anager implementation for single JDBC data sources. It binds a JDBC connection from the specified data source to the currently executing thread, potentially allowing for one thread connection per data source. Application code is required to retrieve the JDBC connection through Data Source Utils.get Connection(Data Source) instead of Java EE's standard Data Source.getConnection. It throws unchecked org.spring frame work.dao exceptions instead of checked SQLExceptions. All framework classes like Jdbc Template use this strategy implicitly. If not used with this transaction manager, the lookup strategy behaves exactly like the common one - it can thus be used in any case.

The Data Source Transaction Manager class supports custom isolation levels, and timeouts that get applied as appropriate JDBC statement query timeouts.To support the latter, application code must either use Jdbc Template or call the DataSourceUtils.applyTransactionTimeout(..) method for each created statement.

This implementation can be used instead of Jta TransactionManager in the single resource case, as it does not require the container to support JTA. Switching between both is just a matter of configuration, if you stick to the required connection lookup pattern. JTA does not support custom isolation levels!


Sometimes you need to access vendor specific JDBC methods that differ from the standard JDBC API. This can be problematic if you are running in an application server or with a Data Source that wraps the Connection,Statement and ResultSet objects with its own wrapper objects. To gain access to the native objects you can configure your JdbcTemplate or Oracle Lob Handler with a Native Jdbc Extractor.

The NativeJdbcExtractor comes in a variety of flavors to match your execution environment:

  • Simple Native Jdbc Extractor
  • C3P0 Native Jdbc Extractor
  • Commons Dbcp Native Jdbc Extractor
  • JBoss Native Jdbc Extractor
  • Web Logic Native Jdbc Extractor
  • Web Sphere Native Jdbc Extractor
  • XA Pool Native Jdbc Extractor

Usually the SimpleNativeJdbcExtractor is sufficient for unwrapping a Connection object in most environments.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Java-Springs Topics