Question

I have the following wrapper:

 public interface ITransactionScopeWrapper : IDisposable
{
    void Complete();
}

public class TransactionScopeWrapper : ITransactionScopeWrapper
{
    private readonly TransactionScope _scope;
    private readonly ISession _session;
    private readonly ITransaction _transaction;

    public TransactionScopeWrapper(ISession session)
    {
        _session = session;
        _scope = new TransactionScope(TransactionScopeOption.Required,
                                      new TransactionOptions {IsolationLevel = IsolationLevel.ReadCommitted});
        _transaction = session.BeginTransaction();
    }

    #region ITransactionScopeWrapper Members

    public void Dispose()
    {
        try
        {
            _transaction.Dispose();
        }
        finally
        {
            _scope.Dispose();
        }
    }

    public void Complete()
    {
        _session.Flush();
        _transaction.Commit();
        _scope.Complete();
    }

    #endregion
}

In my ActionFilter I have the following:

 public class NhibernateTransactionAttribute : ActionFilterAttribute
{
    public ITransactionScopeWrapper TransactionScopeWrapper { get; set; }
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
    }
    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        TransactionScopeWrapper.Complete();

        base.OnActionExecuted(filterContext);
    }

}

I am using Castle to manage my ISession using a lifestyle of per web request:

container.Register(
            Component.For<ISessionFactory>().UsingFactoryMethod(
                x => x.Resolve<INHibernateInit>().GetConfiguration().BuildSessionFactory()).LifeStyle.Is(
                    LifestyleType.Singleton));

container.Register(
            Component.For<ISession>().UsingFactoryMethod(x => container.Resolve<ISessionFactory>().OpenSession()).
                LifeStyle.Is(LifestyleType.PerWebRequest));

container.Register(
          Component.For<ITransactionScopeWrapper>().ImplementedBy<TransactionScopeWrapper>().LifeStyle.Is(
              LifestyleType.PerWebRequest));

So now on to my questions.

1. Any issues with managing the transaction this way
2. Does an ActionFilter OnActionExecuting and OnActionExecuted methods use the same thread.

I ask number 2 because BeginRequest and EndRequest are not guaranteed to operate on the same thread and if you toss transactions on them you will run into big problems.

In my ActionFilter TransactionScopeWrapper is property injected.

Answer 1

There are some other aspects you should also look into.

First I would say is to decide where to dispose of your transaction. Be aware that if you use lazy loading and pass a data entity back to your view and access a property or reference that is configured to be lazy loaded, you’ll encounter problems because your transaction has already been closed in your OnActionExecuted. Though as much as I know you should only use viewmodels in your views, sometimes an entity is a little more convenient. Regardless of the reason if you do want to use lazy loading and access them in your views you’ll have to move your transaction completion into the OnResultExecuted method so that it doesn’t get prematurely committed.

Second you should also look into checking if there were any exceptions or model errors before committing your transaction. I ended up using inspiration from here and here for my final Filter for dealing with my nHibernate Transaction.

Third, if you decide to dispose of your transaction in the OnResultExecuted handler that you do not do so if it’s a request for a child actions. The reason being that like you I scoped my session to the web request, but I found that child actions don’t count as a new request and when they are called and they try to open their own session they were getting the already open session context instead. When the child action then completed it was trying to close ITS session but was actually closing the session used by the parent view as well. This caused any logic after the child action that relied on lazy loaded data to fail as well.

I’d like to go through and try to remove my lazy loaded data from my app when it comes to views but until I get the time to do so you should be aware of these issues that may come up.

I was going to post my own action filter when I realized I had some DRY issues I needed to fix. suffice to say I am checking that filterContext.Exception and filterContext.ExceptionHandled to see if there were any errors and if they have been handled already. Note that just because an exception was handled doesn’t mean that your transaction is OK to be committed. And though this is more subjective to how your app is coded you may also want to check filterContext.Controller.ViewData.ModelState.IsValid before your commit your transaction as well.

UPDATE: Unlike you, I’m using StructureMap, not Castle for Dependency Injection but in my case I added this line to my Application_EndRequest method in the gobal.asax file as a final bit of cleanup. I’m assuming there is something similar in Castle?
StructureMap.ObjectFactory.ReleaseAndDisposeAllHttpScopedObjects();

UPDATE 2: Anyway, a more direct answer to your question. I don’t see anything wrong with using a wrapper like you opt’d to, though I am not sure why you feel the need to wrap it? nHibernate does a really good job of handling the transaction itself so another abstraction layer around that seems unneeded to me. You could just as easily explicitly start the transaction in your OnActionExecuting and explicitly complete it in the OnActionExecuted. By retrieving the ISession object through the DependencyResolver you eliminate any concerns you may have with threading as the IoC container is thread-safe I believe, and from there you can get your current transaction using Session.Transaction and check it’s current state from the IsActive property. My understanding is that it’s possible for the two methods to occur on different threads though, particularly when dealing with an action on a class inheriting from AsynController.