Question

I’ve got a WCF operation conceptually like this:

    [OperationBehavior(TransactionScopeRequired = true)]
    public void Foo() 
    {
        try { DAL.Foo(); return Receipt.CreateSuccessReceipt(); }
        catch (Exception ex) { return Receipt.CreateErrorReceipt(ex); }
    }

If something goes wrong (say, foreign key constraint violaion) in executing the DAL code, control passes to the catch block as I’d expect. But when the method returns, it seems the transaction scope has sniffed out that the transaction failed, and it decides it better throw an exception to make sure to notify the caller about it.

In turn my client application does not get the receipt I want to return, but rather an exception:

System.ServiceModel.FaultException:  
  The transaction under which this method call was executing was asynchronously aborted.

What is wrong with my design?

I could have the service not catch anything, but this has it’s own problems as the service needs to use exception shielding and the client (a batch tool internal to the system) needs to log the error information. The service logs errors too, but not in the same way and to the same place as the batch.

Answer 1

Be careful here! If you set TransactionAutoComplete=true then if the service returns normally the transaction will be committed. Only if there is an unhandled exception (which for the most part you don’t have because you are catching exceptions and returning a receipt message) will the transaction be rolled back. See http://msdn.microsoft.com/en-us/library/system.servicemodel.operationbehaviorattribute.transactionautocomplete.aspx.

Think about a scenario where you successfully executed some DAL calls but some other exception (e.g. NullReferenceException) occurs. Now the transaction will be committed when the method completes because no unhandled exception has occurred but the client receives an ErrorReceipt.

For your scenario, I think you will have to manage the transactions yourself. For example:

[OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = false)]
public Receipt Foo() 
{   
    // Create TransactionScope using the ambient transaction
    using (var scope = new TransactionScope() )
    {
        try { DAL.Foo(); return Receipt.CreateSuccessReceipt(); scope.Complete(); }
        catch (Exception ex) { return Receipt.CreateErrorReceipt(ex); }
    }
}

You could eliminate boilerplate code by creating a helper method that wraps it all within the transaction or you could use policy injection/interception/aspects to manage transactions.

[OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = false)]
public Receipt Foo() 
{   
    return ProcessWithTransaction(() =>
        {
            DAL.Foo();
            return Receipt.CreateSuccessReceipt();
        }
        , (ex) =>
        {
            return Receipt.CreateErrorReceipt(ex);
        }
    );
}

T ProcessWithTransaction<T>(Func<T> processor, Func<Exception, T> exceptionHandler)
{
    using (var scope = new TransactionScope())
    {
        try
        {
            T returnValue = processor();
            scope.Complete();
            return returnValue;
        }
        catch (Exception e)
        {
            return exceptionHandler(e);
        }
    }
}

You mention that you need to use exception shielding. If you are not averse to throwing faults when an error occurs then you could use Enterprise Library Exception Handling Block’s exception shielding which also lets you log the information on the way out (if you desire).

If you decided to go that route your code would look something like this:

[OperationBehavior(TransactionScopeRequired = true)]
public void Foo() 
{
    // Resolve the default ExceptionManager object from the container.
    ExceptionManager exManager = EnterpriseLibraryContainer.Current.GetInstance<ExceptionManager>();

    exManager.Process(() => 
      {
          DAL.Foo(); 
          return Receipt.CreateSuccessReceipt(); 
      }, 
      "ExceptionShielding");
}

Enterprise Library (via configuration) would then catch any exceptions and replace them with a new FaultException that is returned to the client.