Summary

We have seen that Spring's transaction support gives us several advantages over a more traditional J2EE approach. We can easily replace a full-fledged JTA implementation with one that runs against local JDBC transactions without modifying the application code. This is true as long as we are accessing only a single database resource. There is no difference in the programming model regardless of the underlying transaction technology.

Spring's transaction management makes working with JTA transactions just as easy as working with local JDBC transactions. This is especially true if you configure all the transaction components with Spring's IoC framework.

Declarative transactions provided by Spring have several advantages over EJB CMT. They can work without using EJBs and the code can be tested outside of a J2EE container. They provide the option of being configured to roll back automatically on any checked exceptions declared for this purpose.

The additional propagation option of PROPAGATION_NESTED provides the ability to nest a transaction within an existing one allowing for more control and the possibility of restarting a failed transaction from a certain save point. This nested transaction support is available only for single database resources, but it provides a real benefit for applications that can make use of it.

Spring's ability to work equally well with single database resources and JTA resources opens up declarative transactions to a much larger group of applications. There is no specific need to use an application server with JTA support. A plain vanilla Tomcat servlet engine can be used just as well.

Finally, the most important benefit of Spring's transaction framework is that any POJO can be enabled to take advantage of transactions without special requirements or deployment steps. Any existing business service object can be provided with transaction semantics by defining it in a Spring application context and adding a transactional proxy to it. There is no need to modify or rewrite the application like you would have to do to deploy it as an EJB.