Using EFCache but updated data does not show despite calling NotCached

Feb 21, 2015 at 12:20 AM
Edited Feb 21, 2015 at 12:22 AM
I am using EFCache and it really did wonders to improve the speed of EF Queries. But the problem I am having is that despite calling NotCached for certain queries used by the Admin section, update data does not show. I still see the pre-Updated data. I though that EFCache see changes to the date from the client to the database. I suspect you will want me to post a sample and file a bug but prior to that is there anything I need to be considering? The only way to show the updated data is to upload web.config to restart the site. And I am not using TransactionScope either.
Coordinator
Feb 21, 2015 at 6:30 AM
Yes, I need a repro - without a repro I it is hard to tell why .NotCached is not working unless you have multiple servers and the happens on one server while the update on the other server. The InMemoryCache included in the package is local to the app so the cache won't be invalidated for updates that are using a different instance of the cache.
Feb 21, 2015 at 12:10 PM
Edited Feb 21, 2015 at 2:38 PM
When you mean a different server, are you referring to the instance of SQL Server?

Let me ask you, out of the box with just the simple configuration file, EF cache should show the updated data when it goes from client to server, correct?

A little more info for you - the updated data is being shown, just not being shown as soon as a post is updated. SIs that normal behavior for the updated data to not show immediately?

Another question - is there a way to explicitly invalidate the cache when making an update or a new post, thus forcing a refresh of the cache?
Coordinator
Feb 22, 2015 at 7:05 AM
If you for instance had multiple webservers (for instance your web site have a lot of traffic and you are using load balancing) the InMemoryCache would be local to each webserver and, as a result, results cached on this server would not be invalidated if update happened on a different server. Note that this also true if you run multiple instances of the same app on a single machine - the InMemoryCache is a simple mechanism that under the cover is using a static dictionary so is bound to the AppDomain.

The results should be invalidated as soon as data in the table is updated or deleted or to be exact once the transaction for update/delete is committed. Do you by any chance use TransactionScope? If you do this could explain the issue - currently TransactionScope is not supported.

You can invalidate results for given tables using the ICache.InvalidateSets(IEnumerable<string> entitySets) method (note the entitySets is the name of entity sets from the S-Space that correspond to your tables in the database). This however should not be necessary - the idea is that it is done for you if data changes.

Another question - do you use the default caching policy? The default policy is a cache-all policy. In retrospect I don't think it is the best policy. I think that for the best results only entity sets that are rarely modified should be cached. If you modify data for a given table very frequently, especially from multiple clients, caching is not very effective and you may have problems with overwriting newer data by older data (when not using concurrency token) or concurrency exceptions.

Thanks,
Pawel
Feb 22, 2015 at 10:12 PM
No I am not using TransactionScope. I am going to post a video a showing exactly what happens and I would like you to tell me if that is the behavior i should be seeing. I started using the default cache policy and only later did i try manually setting cache/notcached.
Coordinator
Feb 23, 2015 at 5:24 PM
I would prefer to get a repro in form of a project I could run on my box and debug.

Thanks,
Pawel
Feb 23, 2015 at 11:21 PM
I am going to do the repo too - i just want to make sure that the behavior is not typical.
Mar 3, 2015 at 5:04 PM
Hello everybody,

we encounter the same issue as Isudvm.
Are there any news concerning this issue?

We're using Database first with a generic repository and unit of work pattern.
Also our datalayer is located in its own project.

Our Datalayer is implemented based on the following Codeplex project https://genericunitofworkandrepositories.codeplex.com/.

Unfortunately I'am not allowed to provide the project this issue occurs in.

Thanks and best regards from Germany

Marius Stein
Coordinator
Mar 4, 2015 at 2:59 PM
@mstein1

Create a simplified repro so that I can take a look.

Mfg

Pawel
Coordinator
Mar 4, 2015 at 6:30 PM
Actually - can you guys post just the query that uses .NotCached()? Do you dot on the NotCached int the query (i.e. do you compose on it - for instance Users.NotCached().Where(u => u.Name == "John")?
Mar 5, 2015 at 12:18 PM
First of all thanks for your quick answer,

actually we don't use .NotCached() at all. When we update a dbSet and afterwards try to retrieve the updated data from the database, we get the pre-updated data. I just assumed that NotCached will prevent this behavior. Anyway, I will try to create a simplyfied reproduction of this issue and will post it this weekend.

Best regards
Marius Stein
Coordinator
Mar 5, 2015 at 5:36 PM
Marius - do you by any chance use TransactionScope?