Smart Clients and System.Transactions Part 5 – Fixing the Timeout Problem

This is the fifth installment of an ongoing series about using System.Transactions as the fundament for client-side infrastructure for managing changes among loosely coupled components.

Previous posts: Introduction, Timeout, Enlistments, The transaction sink

---

Earlier I discussed the time-out problem which was a serious setback to the plan of building a client side change gathering infrastructure based on System.Transactions. How did we fix this problem? Well, we didn't. Instead we had to resort to cheating:

var scopeFactory = IoC.GetInstance<ITransactionScopeFactory>();
using (var scope = scopeFactory.Start())
{
    // Transactional code

    scope.Complete();
}

 

The above code shows how we now start client side transactions. As you can see, we no longer start a System.Transactions.TransactionScope, but rather look up a factory class (ITransactionScopeFactory) through a service locator, and ask this instance to start a transaction scope. This scope implements the interface ITransactionScope which is defined as  follows:

/// <summary>
/// A scope mimicking the API of System.Transactions.TransactionScope.
/// Defines a single method Complete() used for marking the scope
/// as "successful". This interface extends IDisposable, and when
/// Dispose() is invoked, this scope will instruct the ambient
/// transaction to commit or rollback depending on whether the 
/// scope has been completed or not.
/// </summary>
public interface ITransactionScope : IDisposable
{
    /// <summary>
    /// Marks the scope as complete, resulting in this scope
    /// instructing the ambient transaction to commit when
    /// Dispose() is invoked later on. If Complete() is never
    /// invoked, the scope will force the ambient transaction
    /// to rollback upon Dispose().
    /// </summary>
    void Complete();
}

 

The responsibility of the factory is to determine the type of scope to generate, and this it does by querying the ambient transaction as to whether or not a transaction already has been started. If such a transaction does not exist an instance of ClientTransactionScope is created, and if a transaction already exists, an instance of NestedClientTransactionScope is created. The difference between these two classes lie mainly in their respective constructors and in the Dispose() method:

Constructor and Dispose() of ClientTransactionScope

/// <summary>
/// Initializes a new instance of the <see cref="ClientTransactionScope"/> class.
/// The ambient transaction is automatically started as this instance constructs.
/// </summary>
public ClientTransactionScope()
{
    GetClientTransaction().Begin();
}

 /// <summary>
/// If Complete() has been invoked prior to this, the
/// ambient transaction will be instructed to commit
/// here, else the transaction will be rolled back
/// </summary>
public virtual void Dispose()
{
    if (Completed)
    {
        GetClientTransaction().Commit();
    }
    else
    {
        GetClientTransaction().Rollback();
    }
}

 

Constructor and Dispose() of NestedClientTransactionScope

/// <summary>
/// Initializes a new instance of the <see cref="NestedClientTransactionScope"/> class.
/// This constructor does nothing since an ambient transaction already has been
/// started if an instance 
/// </summary>
public NestedClientTransactionScope()
{}

 /// <summary>
/// If Complete() has been invoked prior to this, nothing happens
/// here. If Complete() has not been invoked, the ambient transaction
/// will be marked as "non commitable". This has ne immediate 
/// consequence, but the transaction is doomed and it will be
/// rollback when the outermost scope is disposed regardless of
/// if this scope attempts to rollback or commit the tx.
/// </summary>
public override void Dispose()
{
    if (!Completed)
    {
        GetClientTransaction().MarkInnerTransactionNotCompleted();
    }
}

 

The comments in the code explain the distinction between these two classes.

Commit and Rollback

The actual task of finishing the transaction, either  by commit or rollback, is the responsibility of the ambient transaction.  Throughout the lifetime of the scope, enlistments that have detected changes have enlisted with the ambient transaction. The exact details of how this enlistment procedure is done is kept hidden from the enlistments, but what actually happens is that the ambient transaction maintains a dictionary in which the enlistments are added.

When the time to commit or roll back has finally arrived, a real System.Transactions.TransactionScope is started, the registered enlistments are enlisted with the transaction, and Complete() is either invoked or not on the scope depending on whether or not the transaction is meant to be committed or rolled back:

/// <summary>
/// Instructs the transaction to begin the two-phased commit procedure.
/// This will be done except if any nested inner transaction scope
/// have instructed the transaction to  rollback prior to this. If this
/// is the case the transaction will roll back the transaction at this
/// point in time.
/// </summary>
public void Commit()
{
    if (!canCommit)
    {
        Rollback();
        throw new TransactionAbortedException("Inner scope not completed");
    }
    using (var scope = new TransactionScope())
    {
        EnlistAll();
        scope.Complete();
    }
}

/// <summary>
/// Instructs the transaction to rollback. This will happen at
/// once if the sending scope is the outer scope (fromInnerScope == true)
/// else the rollback will be postponed until when the outer scope
/// requests a commit
/// </summary>
public void Rollback()
{
    using (new TransactionScope())
    {
        EnlistAll();
        // Don't Complete the scope,
        // resulting in a rollback
    }
}

private void EnlistAll()
{
    var tx = Transaction.Current;
    tx.EnlistVolatile(this, EnlistmentOptions.None);
    tx.EnlistVolatile(sink, EnlistmentOptions.None);
    foreach (var notification in enlistments.Values)
    {
        tx.EnlistVolatile(notification, EnlistmentOptions.None);
    }
}

 

Conclusion

This concludes this series which has been an attempt at showing the benefits and problems that we have seen when realizing a novel idea: using the functionality of System.Transactions as a "change gathering infrastructure". The idea has proved viable, however the "timeout problem" proved to be a serious bump in the road, and forced us to implement code so that the actual functionality of System.Transactions only comes into play in the final moments of the logical scope.