Java Reference
In-Depth Information
Earlier a transaction was defined as being an atomic task. It's a task that's composed of
multiple steps that you want to execute as a single operation. If you're updating five dif-
ferent records in a database—maybe in the same table or different tables—you want the
operations to either all succeed or all fail. Transactions can also be distributed; if you're
talking to two different systems, you also want the same semantics. For example, in Ac-
tionBazaar, if a credit card operation fails, you also want the request to the inventory man-
agement system to be rolled back. So besides being atomic, what are the other properties of
transactions? Many eons ago, Jim Gray coined the acronym ACID: atomicity, consistency,
isolation, and durability.
Atomicity
As we've discussed, transactions are atomic in nature—they either commit or roll back. In
coding terms, if you band together an arbitrary body of code under the umbrella of a trans-
action, an unexpected failure will result in all changes made by that block of code being
undone. The system is thus left in its original state. If the code completes without any fail-
ures, the changes become permanent.
Consistency
This is the trickiest of the four properties because it encompasses more than just writing
code. Consistency refers to the validity of the system—before and after a transaction ex-
ecutes, the system should be consistent with the business rules of the application. It's the
responsibility of the developer to ensure consistency through the use of transactions. The
underlying system, such as a database, doesn't have enough information to know what con-
stitutes a valid state. Whether a transaction succeeds or fails is immaterial—the system will
be in a valid state.
While a transaction is in progress, the system doesn't need to be in a valid state. You can
think of a transaction as a sandbox or sanctuary—you're temporarily protected from the
rules while inside it. But when you go to commit the work done in the sandbox, the system
should be in a valid state that complies with the business rules of the application. Putting
this in the context of ActionBazaar, it's fine to charge a customer even though you haven't
removed the item from bidding while in a transaction. This is safe because the results of the
code will have no impact on the system until and unless the transaction finishes success-
fully. Database constraints help ensure that a database conforms to the rules, but constraints
can't encode all semantic rules.
Search WWH ::




Custom Search