Encapsulating the business logic with a POJO façade - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 257

However, one issue with using exceptions is that calling a façade method can
have several equally valid outcomes. Even validation errors such as invalid delivery
information can be considered normal. This means that choosing the “normal”
outcome is somewhat arbitrary. Another issue is that the exception will typically
need to contain the data that the presentation tier displays to the user, so throw-
ing an exception is not that straightforward.
Because of these shortcomings, my preference is to use exceptions only for
truly exceptional conditions (such as database connection failures) and to use sta-
tus codes to signal application-level errors. However, if the transaction needed to
be rolled back, then I would throw an exception for an application-level error in
order to decouple the business logic from the Spring framework.

7.2.4 Managing transactions and connections

A POJO façade method must usually be executed within a transaction in order to
ensure that it updates the database atomically. The application must start a trans-
action when the POJO façade method is invoked and either commit or roll back
the transaction when it returns. In addition, when the POJO façade method is
invoked the application must open a connection (a JDBC connection, a Hibernate
session, or a JDO PersistenceManager ) and close it after the method returns.
The Spring framework has an AOP -based transaction and connection manage-
ment mechanism. You define Spring beans that wrap your application code with
AOP interceptors that manage transactions and connections. Spring transaction
management, like EJB container-managed transactions, is declarative; you do not
have to write any code.
A valuable feature of Spring transaction management is that although EJB con-
tainer-managed transactions require the application to use JTA transactions,
Spring also provides the option of local transactions, which are lighter weight and
don't require an application server to manage transactions. Furthermore, switch-
ing to JTA transactions (which are only required if an application needs to update
multiple resources such as a database and JMS ) is simply a matter of reconfiguring
a Spring bean.

Configuring the Spring TransactionInterceptor
Declaratively managing transactions with Spring is remarkably easy. You simply have
to use a TransactionInterceptor , which is a Spring AOP interceptor. It intercepts
calls to the POJO façade and ensures that each one executes in the transaction. In
addition, depending on how you have configured the TransactionInterceptor it
will also open and close a database or persistence framework connection.