The Spring Framework provides a consistent abstraction for transaction management that delivers the following benefits:

•  A consistent programming model across different transaction APIs such as JTA, JDBC, Toplink, Hibernate, JPA, and JDO
•  Declarative transaction management
•  A simple API for programmatic transaction management rather than a number of complex transaction APIs such as JTA
•  Integration with Spring's various data access abstractions.

This article discusses Spring's transaction management facilities and the common use cases in Spring where an external transaction manager is required. A real-world application is used to illustrate the transactional aspects and features. The focus is on leveraging JTA transaction management in the Spring Framework for enterprise applications. The article shows how Spring's transaction services can seamlessly expose and interact with a Java EE application server's transaction manager such as the Oracle Application Server and the OC4JJtaTransactionManager.

A traditional bank account transfer application is used in this article to demonstrate basic Spring principles: the classic distributed two-phase commit-transaction use case requiring ACID properties; and Oracle's extended support for Spring with JTA using Spring's OC4JJtaTransactionManager. The transfer in the sample application is from a bank account to a brokerage account for the purchase individual stocks. It includes asset reporting to further illustrate particular transactional aspects and features.

Let's start with an overview of the related technologies, Spring basics, transactioning basics, and transactioning features in Spring. Then we'll look at the implementation strategy and use the sample application to show in more detail how they all work together.

Spring Basics and Features
As a Java EE developer, you may be thinking, "Not another framework." The Spring Framework simplifies development with its modular architecture and handles configuration in a consistent manner. It achieves this simplification by using inversion of control and dependency injection so enterprise functionality can be built into POJOs, making it powerful as well. Spring is a state-of-the-art technology in terms of making Java EE and other existing technologies easier to use. It also provides an abstract level for using JTA or other transaction strategies as well as other J2EE components such as data sources.

Additionally, the Spring Framework can be integrated with different application servers such as Oracle Application Server, BEA WebLogic, and IBM WebSphere.

Spring provides many features. Let's look at the following major areas in detail.

Inversion of Control Container and Dependency Injection
First, let's take a look at how to simplify development by using inversion of control and dependency injection.

A main abstraction of inversion of control is the bean factory, which is a generic factory that retrieves objects by name and manages the relationships between objects.
As Rod Johnson explained in his article on the Spring Framework, the concept behind inversion of control is often expressed in the infamous Hollywood principle, "Don't call me, I'll call you." Inversion of control moves the responsibility for making things happen into the framework and away from the application code.

Dependency injection is a form of inversion of control that removes explicit dependence on container APIs. Ordinary Java methods are used to inject dependencies such as collaborating objects or configuration values into application object instances.

Dependency injection is not a new concept, although it's only recently made prime time in the Java EE community. The definition of dependency injection between the J2EE community and the Spring Framework is the same, but obtained via different mechanisms.

XML Bean Definitions (ApplicationContext)
You can configure your Spring applications in XML bean definition files. In some ways these are similar to the Java EE platform in which you use XML configuration files and XML deployment descriptors to define the relationship of the resources and how they are to be deployed. The root of the XML bean definition is a <beans> element that can contain one or more <bean> definitions.

The following example shows the configuration of the application objects, which is similar to the object relationships we are familiar with in J2EE applications. We will define a J2EE DataSource, bankDataSource; a DAO, bankDAO; and a business object that uses the DAO, assetManagementService. The following examples are from the sample bank account transfer application that shows the relationships between bankDataSource, bankDAO, and assetManagementService.

First, let's look at the bankDataSource definition in XML format. As shown in the following example, we could use Spring's JNDI location FactoryBean to get the data source from the Oracle Application Server. (There would be no impact on Java code or any other bean definitions.)

<beans>
    <bean id="bankDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
       <property name="jndiName">
          <value>jdbc/bankDataSource</value>
       </property>
    </bean>
<beans>