11

I created my own context which inherits from DbContext. Let's assume I have 1 post in my [Posts] table in the database. Consider this scenario:

  1. I ask DbContext for this only post for the first time. And DbContext returns it as expected.
  2. I change one column in [Posts] table manually.
  3. I refresh my site = I ask DbContext for this post again.
  4. DbContext returns a post which has old value for this specific column!

I looked into SQL Profiler and the database IS hit every time I refresh my site, so why the returned post has an old value? I guess DbContext is trying to be very clever and has some internal caching mechanism, but it would be nice to inform me that he's so clever...

Can someone explain this to me?

Darmak
  • 885
  • 2
  • 11
  • 16
  • possible duplicate of [EF 4.0 model caching the data, and does not detect the modified data.](http://stackoverflow.com/questions/3617987/ef-4-0-model-caching-the-data-and-does-not-detect-the-modified-data) – Ladislav Mrnka Sep 10 '10 at 19:54
  • Your question is divided into two already asked questions. Caching problem: http://stackoverflow.com/questions/3617987/ef-4-0-model-caching-the-data-and-does-not-detect-the-modified-data/3621477#3621477 Shared context problem: http://stackoverflow.com/questions/3653009/entity-framework-and-connection-pooling/3653392#3653392 – Ladislav Mrnka Sep 10 '10 at 20:02
  • Is your instance of your `DbContext` static, or is it created on every page request? – Dominic Zukiewicz Jun 04 '14 at 10:58
  • When you say that - "I change one column in [Posts] table manually" then you changed the column value for the record in the dbContext present in memory of you application or you changed the value in your back-end database directly? In case you did the changes in your in-memory dbContext object then did you commit the changes to database before refreshing it? – RBT Mar 25 '16 at 23:46

1 Answers1

0

How are you "refreshing"? If you know a value has changed, you can Refresh the context cached value using ServerWins or ClientWins :

http://msdn.microsoft.com/en-us/library/vstudio/bb738618(v=vs.100).aspx

// Resolve the concurrency conflict by refreshing the 
// object context before re-saving changes. 
context.Refresh(RefreshMode.ClientWins, orders);

However, the real question comes down to when and why this would happen in the first place, which is related to the lifetime of the context. Perhaps you could be over-using the same context? Remember that SQL Server and etc have their own caching mechanism, and thus Entity Framework isn't the only fish in the pond of items trying to do some caching.

From, the following link we gather some tips, which if you were following, you likely wouldn't run into this problem. http://msdn.microsoft.com/en-us/data/jj729737.aspx

  • As you load more objects, memory consumption of the context may increase rapidly
  • Chances of running into concurrency related issues increases with expanded lifetime
  • When working with Web Applications, use a context instance per request
  • When working with Windows Forms, use a context per form
Greg
  • 1,982
  • 17
  • 20