Transactions

A transaction is one or more linked units of processing placed together as a single unit of work, which either succeeds or fails. If the unit of work succeeds, all work is then committed. If the unit fails, then every item of processing is rolled back and the process is returned to its original state.

The standard transaction example involves transferring money from account A to account B. The money must either end up in account B (and nowhere else), or - if something goes wrong - stay in account A (and go nowhere else). This avoids the very undesirable case in which we have taken money from account A but haven’t put it in account B.

The ACID Test

Transaction theory starts with ACID. According to the ACID theory, all transactions should have the following properties:

• Atomicity - A transaction is atomic; that is, everything is treated as one unit. However many different components the transaction involves, and however many different method calls on those components there are, the system treats it as a single operation that either entirely succeeds or entirely fails. If it fails, then the system is left in the state it was in before the transaction was attempted.

• Consistency - All changes are done in a consistent manner. The system goes from one valid state to another.

• Isolation - Transactions that are going on at the same time are isolated from each other. If transaction A changes the system from state 1 to state 2, transaction B will see the system in either state 1 or 2, but not some half-baked state in between the two.

• Durability - If a transaction has been committed, the effect is permanent, even if the system fails.

Let’s illustrate this with a concrete example. Imagine that, having spent a happy afternoon browsing in your favorite bookstore, you decide to shell out some of your hard-earned dollars for a copy of, yes, Professional VB 2005 with .NET 3.0 (wise choice). You take the copy to the checkout, and exchange a bit of cash for the book. A transaction is going on here: You pay money and the store provides you with a book.

There are only two reasonable outcomes either you get the book and the store gets its money or you don’t get the book and the store doesn’t get its money. If, for example, there is insufficient credit on your card, then you’ll leave the shop without the book. In that case, the transaction doesn’t happen. The only way for the transaction to complete is both for you to get the book and the store to get its money. This is the principle of atomicity.

If the store provides you with a copy of some other book instead, then you would reasonably feel that you ended up with an outcome that was neither anticipated nor desirable. This would be a violation of the principle of consistency.

Now imagine that there is one copy of the book in the store, and another potential buyer of that book has gone up to the cashier next to you. As far as the person at the other cashier is concerned, your respective transactions are isolated from each other (even though you are competing for the same resource). Either your transaction succeeds or the other person’s does. What definitely doesn’t happen is that the bookstore decides to exert the wisdom of Solomon and give you half each.

Now suppose you take the book home and the bookstore calls you to ask if they can have the book back. Apparently, an important customer (well, far more important than you, anyway) needs a copy. You would find this a tad unreasonable, and a violation of the principle of durability.

At this point, it’s worth considering what implications all this is likely to have on the underlying components. How can you ensure that all of the changes in the system can be unwound if the transaction is aborted at some point? Perhaps you’re in the middle of updating dozens of database files and something goes wrong.

There are three aspects to rescuing this situation with transactions:

• Knowledge that something has gone wrong

• Knowledge to perform the recovery

• Coordination of the recovery process

The middle part of the process is handled by the resource managers themselves; the likes of SQL Server and Oracle are fully equipped to deal with transactions and rollback (even if the resource manager in question is restarted partway through a transaction), so you don’t need to worry about any of that. The last part of the process, coordination, is handled by the .NET runtime (or at least the Enterprise Services part of it). The first part, knowing that something is wrong, is shared between the components themselves and the .NET runtime. This isn’t at all unusual: Sometimes a component can detect that something has gone wrong itself and signal that recovery is necessary, while on other occasions it may not be able to do so, because it has crashed.

Later, you will see how all this works as you build a transactional application.