Java Reference
In-Depth Information
On another technical note, demarcating your transactions at the business logic
layer also allows you to have multiple interfaces to your application while main-
taining a single, consistent transaction model.
So what do you think? Does demarcating transactions at the business logic layer
feel natural? Well, it should. Architects, database administrators, and developers
often think of transactions as a technical concept. After all, a transaction is “some-
thing that a database does.” But we should think of transactions at a higher level. A
transaction scope should encompass a business operation or a business function. It
shouldn't just be thought of as a database feature. Furthermore, databases are not
the only infrastructural elements that support transactions. Our business operation
may include calls through a connector to a mainframe or publishing messages to a
message queue, or it may even involve human intervention (think workflow) as part
of the transaction—all of which may indeed support transactions.
The business layer is a perfect place to demarcate transactions, both logically
and technically speaking.
7.7 Summary
In this chapter we discussed transactions, what they are, and how to use them
within i
BATIS
. We discussed the
ACID
properties that are imperative for proper
transaction management. Atomicity ensures that all transaction steps succeed or
fail as a group. Consistency ensures that all database constraints are met both at
the beginning and at the end of a transaction. Isolation ensures that concurrent
transactions do not unexpectedly conflict with each other. Durability ensures that
the data is safe once the transaction has successfully completed.
We discussed the various transaction scopes, including automatic transactions,
local transactions, global transactions, and custom transactions. Automatic trans-
actions are the narrowest-scoped transactions, involving only a single statement,
but within a transaction nevertheless. Local transactions are wider-scoped transac-
tions involving multiple update statements, but still only a single application with
a single database. Global transactions are much more complicated and allow for
transactions to span multiple databases, resources, and applications. Custom
transactions provide a means for developers to gain full control over the connec-
tion, and therefore the transaction, used by i
BATIS
.
Local transaction scope, including automatic transactions, is the narrowest
scope that should be used for any application involving a relational database. Glo-
bal transactions should be used whenever multiple resources are involved. Cus-
tom transactions (user-provided connections) should be used judiciously and, if
possible, avoided by writing a custom transaction manager implementation.
