Transactions - iBATIS in Action - page 160

transactions. The disadvantage of this approach is that performance may suffer with
such long-lived transactions. The presentation layer is also generally unaware of
exactly why the transaction is being started, as it is quite far from the persistence
layer. As a result, many transactions can end up being unnecessarily long-lived. The
other disadvantage is that if you have multiple user interfaces for your application,
such as a website, a web services API , and a rich client, then you must reimplement
the transaction scopes for each UI , which can create some inconsistencies.
Since the presentation tier is too far away from the persistence layer to be a log-
ical place to demarcate transactions, why not go straight to the persistence layer?

7.6.2 Demarcating transactions at the persistence layer

The persistence layer is where most people would naturally think to demarcate
transactions. However, it makes a surprisingly poor choice. The reason is that a
good persistence layer is built of rather narrowly scoped methods, loosely coupled
and yet highly cohesive database operations. It's actually rare that one would use a
single one of these operations alone within a transaction, as that would make the
transaction rather useless. It's more common that a group of these database oper-
ations requires execution to perform some useful business function. So the persis-
tence layer is simply too fine grained. It's possible to build an additional layer that
binds these groups of persistence operations together, and therefore makes for a
sensible choice for transaction demarcation. However, that's creating more
unnecessary work and complicates the design, all for the sake of something that
should ideally be transparent.

7.6.3 Demarcating transactions at the business logic layer

Having eliminated the presentation and persistence layers, we are left with the busi-
ness logic layer, which you've probably guessed is the right choice. Well, as we've
said before, depending on the application requirements, any one of these layers
could be the right choice. However, experience has shown that the business logic
layer often makes a good choice for demarcating transactions. This is a common
and familiar approach to both EJB developers and Spring framework developers
alike. Stateless session beans are a business logic component, and often transaction
requirements are declared as part of their configuration. In a similar way, Spring
allows transactions to be declared for almost any method, and often the business
logic components are chosen over the DAO s, simply because it's common for a sin-
gle business operation to require more than one DAO .