MSDN Magazine - January 2009 - (Page 109)

JuvAl lowy Foundations Easily Apply Transactions To Services A fundamental problem in programming is error recovery. After an error, your application must restore itself to the state it had before the error took place. Consider an application that tries to perform an operation comprising several smaller operations, potentially concurrently, where each of the individual operations can fail or succeed independently of the others. An error in any one of the smaller operations means the system is at an inconsistent state. Take a banking application, for example, that transfers funds between two accounts by crediting one account and debiting the other. Successfully debiting one account but failing to credit the other is an inconsistent state, because the funds cannot be in both places at the same time, and failing to debit while successfully crediting results with an equally inconsistent state in which the money is gone. It is always up to the application to recover from the error by restoring the system to the original state. This is far easier said than done for a number of reasons. First, for a large operation, the sheer number of permutations of partial success and partial failure gets quickly out of hand. This results in fragile code that is very expensive to develop and maintain and quite often does not really work, since developers often deal only with the easy recovery cases, which are the cases that they are both aware of and know how to handle. Second, your composite operation could be part of a much larger operation, and even if your code executed flawlessly, you still may have to undo it if something else outside your control encounters an error. This implies tight coupling between the participating parties on the management and coordination of the operations. Finally, you also need to isolate what you do from whomever else is required to interact with the system, because if you later on recover from an error by rolling back some of your actions, you will put someone else implicitly in an error state. As you can see, it is practically impossible to write robust error-recovery code by hand. This realization is not new. Ever since software was used in business contexts (in the 1960s), it was clear there had to be a better way of managing recovery. There is a better way: transactions. A transaction is a set of operations where the failure of any individual operation causes the entire set to fail, as one atomic operation. When using transactions, there is no need to write recovery logic, since there is nothing to recover. Either all operations succeeded so there is nothing to recover, or they all failed, and failed to affect the system’s state, so there is also nothing to recover. Figure 1 Using Transactional Transactional number = new Transactional (3); Transactional city = new Transactional ("New York, "); city.Value += "NY"; //Can use with or without transactions using(TransactionScope scope = new TransactionScope()) { city.Value = "London, "; city.Value += "UK"; number.Value = 4; number.Value++; } Debug.Assert(number == 3); //Conversion operators at work Debug.Assert(city == "New York, NY"); When using transactions, it is essential to use transactional resource managers. The resource manager is capable of rolling back all changes made during the transaction if the transaction aborts and persisting the changes if the transaction commits. The resource manager also provides isolation; that is, while a transaction is in progress, the resource manager prevents all other parties (besides the transaction) from accessing it and seeing the changes, which could still roll back. This also means that the transaction should never access non-resource managers, since any changes made to those will not roll back if the transaction aborts, and thus recovery will be necessary. Traditionally, resource managers were durable resources such as databases and message queues. However, in the article from the May 2005 issue of MSDN Magazine titled “Can’t Commit? Volatile Resource Managers in .NET Bring Transactions to the Common Type” (see msdn.microsoft.com/magazine/cc163688), I presented my technique for implementing a general-purpose volatile resource manager (VRM) called Transactional : public class Transactional : { public Transactional(T value); public Transactional(); public T Value {get;set;} /* Conversion operators to and from T */ } By specifying any serializable type parameter (such as an int or a string) to Transactional , you turn that type into a full-blown Send your questions and comments to mmnet30@microsoft.com. Code download at code.msdn.microsoft.com/mag200901Foundations. January 2009 109 http://msdn.microsoft.com/magazine/cc163688 http://code.msdn.microsoft.com/mag200901Foundations

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2009

Toolbox CLR Inside Out Basic Instincts Cutting Edge Test Run First Look� Geneva Framework Silverlight Windows Mobile Service Station Security Briefs Extreme ASP.NET Foundations .NET Matters { End Bracket }

MSDN Magazine - January 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.