Entity Framework returning old data

Question

I have a problem with EF not returning the newest data in a 3 layered WPF application, and I suspect it has something to do with how I handle the lifetime of my context. This is the scenario:

There are several repositories wrapped inside a UnitOfWork. There is also one service (MyService), which uses the UnitOfWork. This UnitOfWork must also be called from the UI directly, without passing through a service.

In the ViewModel of my main window at some point I create a new window (using ViewModel first):

var dialog = new DialogViewModel(_eventAggregator, _unitOfWork, Container.Resolve<CarService>());

This main window ViewModel has a UnitOfWork, which has been injected in the constructor, and that is passed to the DialogViewModel.

CarService's constructor also needs a UnitOfWork, which is also injected in its constructor:

public CarService(IUnitOfWork unitOfWork){
    _unitOfWork = unitOfWork;
}

When CarService is used in DialogViewModel to make a query to retrieve some data and make some updates, it works fine the first time. However, when the same query is made the next time to retrieve that data, instead of returning the newest modified one it returns the old/cached one. The query using UnitOfWork (inside CarService) looks like this:

var values = _unitOfWork.GarageRepository.GetSomeValues();
_unitOfWork.GarageRepository.MakeSomeChangesToTheValuesUsingStoredProcedure();

The second time this is called, values doesn't contain the newest version of the data; however it has been updated successfully in the DB.

I'm doing DI using Unity, and this is how my container looks like:

public class Container
{
     public static UnityContainer Container = new UnityContainer();

     // Called once in the AppBoostraper, as soon as the GUI application starts 
     public void BuildUp()
     {
          Container.RegisterType<IUnitOfWork, UnitOfWork>();
          Container.RegisterType<ICarService, CarService>();
     }
}

Why isn't the right data being returned, and how can I fix it?

Note: the data change is made with a call to a stored procedure, not modifying the entities in the context. — chuwik, Jan 22 '13 at 11:58

score 29 · Accepted Answer · answered Jan 22 '13 at 15:27

I finally found the problem, which had to do with my management of the unitOfWork/dbcontext lifecycle.

I was loading some entities, then updating them with a stored procedure (so the entities in the code were not up to date anymore), and then loading the queries again; at this point EF was getting the values from the cache rather than from the DB.

I found two ways of fixing this:

A rather "hacky" one, force the entities to reload:
```
Context.Entry(entity).Reload();
```
Encapsulate the unitOfWork usage with a using, so that the context is disposed at the end of each transaction and thus getting fresh data the next time. I think this is more in line with what the UnitOfWork is meant for and feels more robust to me. I've also wrapped the UnitOfWork in a factory, so now that gets injected in the constructors.
```
using (var uOw = new unitOfWorkFactory.GetNew())
{
     // make the queries
}   
```

Nick · Answer 2 · 2013-01-22T04:04:21.167

The default LifetimeManager for Unity is the TransientLifetimeManager, which means you get a new instance each time it resolves (including when injected). So given your registrations, you'll get a new CarService, with a new instance of a UnitOfWork each time you call Resolve(), and a new, different instance injected into your main window ViewModel.

So your ViewModel gets a UoW, the CarService gets a separate UoW, and updating one will mean the other is now out of date due to caching.

What you need to do is set up a LifetimeManager for the context that has appropriate scope, or defer to a factory. Unity doesn't have that many LMs built in, but the LifetimeManager class is basically a glorified map (has a Set, Get, and Remove method essentially).

I don't know enough about WPF and its lifetimes to suggest an implementation. Maybe it can be singleton (which will keep the same context the entire time the program is running), maybe it can be backed by a thread's CallContext.

Your other option is to pass along the UoW instance when you resolve the CarService by calling Container.Resolve<CarService>(new ParameterOverride("unitOfWork", _unitOfWork)). That'll keep the lifecycle management tied to the lifetime of the main window ViewModel. However, this approach has problems because your VM class knows a little too much about the CarService (notably, that it has a UoW in it).

Thanks for your answer. However, I had confused the DialogViewModel constructor, and have updated the question changing this and clarifying other parts (both queries are run when DialogViewModel invokes the CarService method to read/update data, so I guess they both use the same instance). My application is done in WPF, so there's no ASP involved in it. — chuwik, Jan 22 '13 at 01:24
Oops, you're right. The basic problem remains the same: you have two different UoW instances at once: one in the CarService, and one in the ViewModel. The edit describes some possible solutions. — Nick, Jan 22 '13 at 04:05
I've tried your options, changed the lifetimemanager of UnitOfWork to be a singleton, even modified the code to pass the same _unitOfWork directly just to see if it worked; in every instance, still old data is being returned. — chuwik, Jan 22 '13 at 11:56

Entity Framework returning old data

2 Answers2

Linked