Developing with POJOs: faster and easier - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 24

1. Call transfer() 3. Call transfer()

Presentation
Tier

Transaction
Interceptor

TransferFacade
Impl

6. transfer() returns 4. transfer() returns

2. Begin transaction

5. Commit transaction

Platform
Transaction
Manager

Figure 1.6 Using Spring interceptors to manage transactions

Let's look at the sequence of events:

1 The presentation tier calls TransferFacade but the call is routed to Trans-
actionInterceptor .
2 TransactionInterceptor begins a transaction by calling PlatformTransac-
tionManager , which begins a transaction using either the JTA provided by
the application server or the transaction management API provided by the
persistence framework.
3 TransactionInterceptor invokes the real TransferFacadeImpl .
4 The call to TransferFacadeImpl returns.
5 TransactionInterceptor commits the transaction by calling Platform-
TransactionManager .

The call to TransactionInterceptor returns.

6

In step 5 TransactionInterceptor could also roll back the transaction if the
TransferMoney service threw an exception. By default, TransactionInterceptor
emulates EJB s and rolls back a transaction if a RuntimeException is thrown.
However, you can write rollback rules that specify which exceptions should cause
a transaction to be rolled back. Using rollback rules simplifies the application and
decouples it from the transaction management API s by eliminating code that
programmatically rolls back transactions. This is one example of how the Spring
framework is more flexible than an EJB container.
Another benefit of using Spring is that you can test your transactional POJO s
without deploying them in the application server. Because code that uses JDO or
Hibernate can also be tested within your IDE , you can often do a lot of development