Now, we define the DAO bean that has a bean reference to the bankDataSource. Relationships between beans are specified using the "ref" attribute or <ref> element:

<beans>
    <bean id="bankDAO" class="how.to.spring.tx.BankImpl">
       <property name="dataSource">
          <ref bean="bankDataSource"/>
       </property>
    </bean>
<beans>

The business object, assetManagementService, has a reference to the DAO as in the following example:

<beans>
    <bean id="assetManagementService" class="how.to.spring.tx.AssetManagementServiceImpl">
       <property name="brokerage">
          <ref local="brokerageDAO"/>
       </property>
       <property name="bank">
          <ref local="bankDAO"/>
       </property>
    </bean>
<beans>

ContextLoaderListener and DispatcherServlet
ContextLoaderListener is the bootstrap listener to start up Spring's root webApplicationContext when integrating with a J2EE Web container. As the example shows, the J2EE standard web-app descriptor, web.xml, can include a Spring ContextLoaderListener listener that causes the WEB-INF/applicationContext.xml specified by the contextConfigLocation <context-param> to be loaded by the Spring Framework. The Spring DispatcherServlet servlet deployed with the servlet-name jta-spring causes the jta-spring-servlet.xml to be loaded by the Spring Framework:

<web-app>
    <display-name>JTA Spring Integration WebApp</display-name>
    <context-param>
       <param-name>contextConfigLocation</param-name>
       <param-value>WEB-INF/applicationContext.xml</param-value>
    </context-param>
    <listener>
        <listener- class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    <servlet>
       <servlet-name>jta-spring</servlet-name>
       <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
          <load-on-startup>2</load-on-startup>
    </servlet>
    <servlet-mapping>
          <servlet-name>jta-spring</servlet-name>
          <url-pattern>JTADispatcherServlet</url-pattern>
    </servlet-mapping>
</web-app>

Transactioning Basics
When purchasing stocks from a broker, money is transferred from a bank account to the brokerage. A series of related operations ensures that the stocks are added to the purchaser's portfolio and the brokerage, in turn, gets the purchase money. If a single operation in the series fails during the exchange, the entire exchange fails. You don't get the stocks and the broker doesn't get your money. Transaction processing makes the exchange balanced and predictable even in the face of failures in any of the systems or resources involved.

ACID Properties
Transaction processing systems provide the guarantee of ACID properties.

ACID properties include atomicity, consistency, isolation, and durability.
•  Atomicity: All changes within the scope of a transaction (the unit of work) are either committed or rolled back. For example, a consumer obtains stocks and a broker receives the payment, or the consumer doesn't get the stocks and the broker doesn't get the payment.
•  Consistency: The state (data) of the system moves from one valid state to another from the beginning of the transaction to its completion. This applies to both the infrastructure and the applications. For example, in a stock purchase, the integrity constraints that are defined on the database of either the consumer or the brokerage are maintained.
•  Isolation: The effects of one transaction aren't visible to another until the transaction completes. For example, the effects of a stock purchase aren't visible to an asset report until the purchase is complete.
•  Durability: Changes made within the scope of the transaction must be made permanent. For example, the records of the transfer of money to a brokerage account are written to stable storage.

It's entirely possible to make these guarantees without any supporting infrastructure, but this would require a considerable amount of error-prone and repetitive work by the application developer and generally a less flexible design. Transaction processing systems, and the application servers they run within, provide this service implicitly.

Many transactioning systems and applications allow relaxing one or more of the ACID properties. Often, this is done to provide better performance once a risk assessment has been done and/or an acceptable tolerance established. Isolation is the most commonly relaxed property.

Isolation Levels
An isolation level defines how concurrent transactions that access a shared resource are isolated from one another for read purposes.

Dirty reads, non-repeatable reads, and phantom reads are the three main conditions in which an application reads data in a transaction that has been altered outside of the transaction.