Transaction Management
Comprehensive transaction support provided by Spring can be one of the compelling reasons to use this framework. It does support this with high level abstraction, which makes the coding simpler and easier. Simpler API’s for programmatic transaction management and support for declarative transaction management is the core support provided by the Spring framework for easing development effort by developers.
Since this topic is very important in developing you application, this topic demands special mention and is covered in full detail in Chapter 9.
Connection Management
A common requirement of any enterprise applications is to efficiently manage a database connection. Spring can help you solve this problem by providing an Inversion of Control infrastructure, allowing you to inject connection management implementation in dependent code. The IoC infrastructure is an important feature, because it lets you shift to a more efficient connection management implementation, even at the later stages of project development. Another advantage of using Spring is that it gives you a rich set of ready-made beans, which take care of any low-level plumbing tasks in connection management.
If you have many Data Access Objects (DAO’s) in your application, IoC pattern suggests that you create your connection somewhere outside the application and inject it to each DAO’s. This enables application to switch to a different connection management implementation at any stage in application development as described earlier. This approach makes your application much more flexible and easy to test. Since Spring is an IoC container, it goes one step further: not only does it suggest that you should have connection management logic in a separate bean, but it also provides org.springframework.jdbc.datasource.DriverManagerDataSource implementation class of the standard JDBC javax.sql.DataSource interface, configuring the plain old JDBC DriverManager via bean properties, and returning a new connection from wherever getConnection() method is called. Listing 8-1 shows configuring DriverManagerDataSource bean in XML. You can now inject the datasource configured in XML as bean in your DAO’s and use it to get the actual connection object.
Listing 8-1. Configuration of DriverManagerDataSource bean in XML
|
1 2 3 4 5 6 7 8 9 10 11 |
<bean id="driverManagerDataSource"> <property name="driverClassName" value="org.apache.derby.jdbc.ClientDriver"/> <property name="url" value="jdbc:derby://localhost:8080/sampleDB"/> <property name="username" value="admin"/> <property name="password" value="password"/> </bean> |
Spring provides another implementation class for javax.sql.DataSource interface namely SingleConnectionDataSource. It extends the DriverManagerDataSource class and wraps a single connection that’s not closed after use. One of the main problems of the DriverManageDataSource class is that it opens a new physical connection every time the application calls its getConnection() method (very costly operation). The SingleConnectionDataSource implementation solves this problem by caching the connection on its first invocation and returning the same connection each time its getConnection() method is called. Listing 8-2 shows configuring SingleConnectionDataSource in your Spring XML configuration.
Listing 8-2. Configuring SingleConnectionDataSource in your Spring XML configuration
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<bean id="singleConnectionDataSource"> <property name="driverClassName" value="org.apache.derby.jdbc.ClientDriver"/> <property name="url" value="jdbc:derby://localhost:8080/sampleDB"/> <property name="username" value="admin"/> <property name="password" value="password"/> <property name="suppressClose" value="true"/> </bean> |
It is important to note that the value of suppressClose is false by default, so if you declare SingleConnectionDataSource without specifying the value of the suppressClose flag as true, then the getConnection() method won’t wrap a real connection object into a proxy. As a result, when you call the close() method upon connection for the first time, the real connection to the database is closed. After that, when you try to call the getConnection() method, Spring returns a closed connection, resulting in an SQLException. Spring documentation recommends that the SingleConnectionDataSource be used in an out-of-container environment when you’re developing a single-threaded application.
However a problem with both DriverManagerDataSource and SingleConnectionDataSource is that they don’t handle connections efficiently, and as a result, they’re not good choices for a typical real world enterprise application. The development of enterprise applications requires pooling of database connections. Spring doesn’t provide its own implementation of the pooled connection DataSource. You can either use open source implementation like Apache DBCP’s BasicDataSource or C3P0’s ComboPooledDataSource implementation for your application. Listing 8-3 shows configuring connection pool using Apache DBCP and Listing 8-4 shows configuring connection pool using C3P0.
Listing 8-3. Configuring Apache DBCP connection pool in Spring XML configuration
|
1 2 3 4 5 6 7 8 9 10 |
<bean id="apacheDBCPDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="org.apache.derby.jdbc.ClientDriver"/> <property name="url" value="jdbc:derby://localhost:8080/sampleDB"/> <property name="initialSize" value="5"/> <property name="maxActive" value="20"/> <property name="poolPreparedStatements" value="true"/> <property name="username" value="admin" /> <property name="password" value="password" /> </bean> |
Listing 8-4. Configuring C3P0 connection pool in Spring XML configuration
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<bean id="c3p0DataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close"> <property name="driverClass value="org.apache.derby.jdbc.ClientDriver"/> <property name="jdbcUrl" value="jdbc:derby://localhost:8080/sampleDB"/> <property name="properties"> <props> <prop key="c3p0.acquire_increment">5</prop> <prop key="c3p0.maxStatementsPerConnection">20</prop> <prop key="c3p0.maxStatements ">100</prop> <prop key="c3p0.maxPoolSize">20</prop> <prop key="c3p0.max_statements">0</prop> <prop key="c3p0.minPoolSize">5</prop> <prop key="user">admin</prop> <prop key="password">password</prop> </props> </property> </bean> |
Page Visitors: 10635
Tomcy John
Latest posts by Tomcy John (see all)
- A Guide to Continuous Improvement for Architects - February 2, 2023
- Cloud-first Architecture Strategy - January 26, 2023
- Architecture Strategy and how to create One - January 24, 2023
Hi my friend! I wish to say that this article is awesome, nice written and come with approximately all important infos. Iˇ¦d like to peer more posts like this .
simple, well written. keep writing..