Question

I’ve googled around the “Row Not Found or Changed” error for some time, and I’m just unable to see how the error is being caused in my application.

I have a facade class, called DataAccess, which wraps multiple repositories, and gets passed around my application. Every controller has a dependency upon DataAccess, so I’ve hooked it up to unity to pass out as required.

Data Access looks roughly like this, in truncated/abstracted form:

public class DataAccess : IDataAccess
{
    private MyDataContext DataContext = new MyDataContext();

    public Repository1 Repo1 = new Repository1();
    public Repository2 Repo2 = new Repository2();

    public DataAccess()
    {
        Repo1.DataContext = DataContext;
        Repo2.DataContext = DataContext;
    }
}

Then each controller has a dependency upon IDataAccess like so:

public class MyControllerBase
{
    [Dependency]
    IDataAccess DataAccess { get; set; }
}

Unity hands these out according to what appears to be normal configuration, registering types in Global.asax, hooking controllers up to a factory, resolving with unity. Furthermore, I’ve registered it with a PerThreadLifetimeManager(), which I am unsure whether is correct.

For the most part this works great – however the problem can be reproduced by:

• Go to Edit action and post an edit (redirects to Index)
• Go back into the Edit action and attempt to post another edit, OR, go into Delete action and attempt to post a Delete on the same item

This throws the “Row Not Found or Changed” error. Each action (Edit and Delete) calls SubmitChanges() on the DataContext. So I’m not quite sure what’s going on here. If anyone has any ideas they would be extremely well received.

Cheers,

Tim.

Answer 1

I suspect the per-thread lifetime is not appropriate here – ASP.NET reuses threads across requests, and that would result in reusing your old contexts across multiple requests, possibly leaving them in odd states.

You have two choices:

1. If you only call container.resolve on the controller, then you could use the built-in PerResolveLifetimeManager instead. This would give you a single DataAccess object per controller resolve.
2. You could grab one of the many PerRequestLifetimeManager implementations and get a new DataAccess object per HttpRequest.

Either way will, I suspect, get you out of the issues you’ve got currently.