My New Laptop

July 31, 2010

After more than three years wielding my trusty Dell XPS M1210, I felt it was time to upgrade to a Dell Alienware M15x. This is also a history of the laptops I used during the last three and a half years. Three and a half years ago I bought a Dell XPS M1210 with an Intel Core 2 Duo CPU @ 1.86 GHz, 2 GB of memory, and a 120 GB 5400 RPM hard drive. This laptop has a 12.1” display. Two years ago I bought an Asus...
one comment

Debugging Distributed Transactions: Transactional Deadlocks, Part 2

July 22, 2010

It’s time to add WCF services to the mix and see how their presence adds to the complexity of the otherwise non-trivial transactional deadlocks. Consider the following transaction: Client: Begin transaction Client: Select all orders by customer A Client: Call a WCF service and pass to it the list of orders Service: Update the shipping date of all selected orders Client: Commit If both parties share the same distributed transaction, it completes successfully. However, if the...
no comments

Debugging Distributed Transactions: Transactional Deadlocks, Part 1

July 19, 2010

The most commonly encountered problem with distributed transactions is that of transactional deadlocks. Transactions guarantee isolation, which is usually effected through locks. This is the case with SQL Server (as well as other relational databases) transactions. Transaction isolation levels provide additional granularity as to when and whether the locks are released prior to the completion of the transaction. Database Locks Simply put, the database issues shared (read) and exclusive (write) locks on data touched by the transaction. For most practical purposes, a SELECT statement effects a shared lock on all the rows returned by the statement, while...
no comments

Debugging Distributed Transactions: Fault Handling

July 17, 2010

How is a WCF service call under a distributed transaction different from a regular WCF service call? The primary difference is the transactional abort semantics in case of failure. If the WCF service operation fails when there is no ambient transaction, the failure can be contained—the service caller may decide to ignore the error and proceed. However, if the WCF service operation fails within a distributed transaction, the transaction’s abort flag is set (by default), so that the caller cannot proceed with the transaction. In other words, if you handle a fault from a transactional WCF service and...
no comments

Debugging Distributed Transactions: Configuring WCF Transaction Flow

July 14, 2010

This is the first in a short series of posts in which we’ll debug problems that arise from the use of distributed transactions in WCF. Particularly, we will look into deadlocks, timeouts, and miscellaneous transaction-related issues. To begin with, here’s a brief recap of what has to be done to flow a transaction across WCF service calls: The WCF operation must be decorated with the attribute and the TransactionFlowOption enum. You can either disallow, allow, or mandate transaction flow to the service operation—violations of the contract result in a ProtocolException on the caller’s...
no comments

Generic Method Dispatch

July 9, 2010

Inside a method that is generic in T you may invoke on an expression of type T any of the System.Object methods, or methods that belong to the class or interface constraints of T. Because the JIT does not invoke a full-blown compiler when generating code for a specific type T, there is a significant difference in performance when invoking methods on value types in this fashion. Assume the following value type describes a point in two-dimensional space. The value type overrides ValueType.Equals and provides an overload with the same name, as per the value type best practices:...
no comments

Enumerator Structs: Optimizing for the Common Case

July 5, 2010

I read a couple of posts by Simon Cooper where he explains in great details why mutable structs are bad, and how the BCL’s enumerator structs (e.g. LinkedList<T>.Enumerator) are prime candidates for this anti-pattern. He dissects a really nasty bug where declaring a value type field as readonly effects unexpected copy semantics if the value type is modified. The following code enters an infinite loop (which prints 0 indefinitely): class EnumeratorWrapper{    private readonly LinkedList<int>.Enumerator _enumerator;    private readonly LinkedList<int> _list;     public EnumeratorWrapper()    {        _list = new LinkedList<int>(Enumerable.Range(0,5));        _enumerator = _list.GetEnumerator();         PrintAll();    }     private void PrintAll()    {        while (_enumerator.MoveNext())        {            Console.WriteLine(_enumerator.Current);        }    }} The reason...