Bug Report

Sep 24, 2014 at 3:29 PM
mvc5 + EF6
If I install the package glimpse.ef6 into this project, 2nd level cache will not invalidate the data in cache.I follow into the source code to find out what it's happended.

in CacheTransactionHandler.cs
public virtual void InvalidateSets(DbTransaction transaction, IEnumerable<string> entitySets)
        {
            if (transaction == null)
            {
                _cache.InvalidateSets(entitySets);
            }
            else
            {
                AddAffectedEntitySets(transaction, entitySets);
            }
        }
I found transaction always is not null , because of glimpse.ef6 ,so cache will never excute method InvalidateSets.

Can you fix this ?
Coordinator
Sep 24, 2014 at 6:28 PM
I have not tried glimpse - how do they hook up into to the EF pipeline (i.e. how you configure it to run with EF)?
Sep 24, 2014 at 9:12 PM
Edited Sep 24, 2014 at 9:15 PM
if you want to try it :
create new mvc5 project,then install package glimpse.ef6,entityframework.cache, glimpse will auto cofing your web.config
Coordinator
Sep 25, 2014 at 6:17 AM
Thanks, I will take a look.
Sep 26, 2014 at 4:20 PM
Edited Sep 26, 2014 at 4:21 PM
Hello iwaitu,

just wanted to share my experience. please ignore if your case is different.

I am using glimpse too, i saw the same behavior. my items were not getting invalidated. i saw the transaction was always not null, but when i debugged past that line, i went into below "Committed" method which is invalidating the items.

in CacheTransactionHandler.cs

public void Committed(DbTransaction transaction, DbTransactionInterceptionContext interceptionContext)
    {
        var entitySets = RemoveAffectedEntitySets(transaction);

        if (entitySets != null)
        {
            _cache.InvalidateSets(entitySets.Distinct());
        }
    }
My actual problem was different. i was implementing my own cache and had bug in invalidating items.

Karthik
Sep 28, 2014 at 4:34 PM
Thank you very much ! @karthikmuthyala , It's work.
Coordinator
Sep 29, 2014 at 7:39 PM
@iwaitu - I read your post incorrectly and therefore did not notice that the behavior (as pointed out by @karthikmuthyala) is by design. Here is a longer version of the story. EF always saves changes (create/update/delete operations) in a transaction. This is to make sure to leave the database in a consistent state - either all changes you have made to your entities are saved or none of the changes are saved (and an exception is thrown). Note that typically more than one entity is being changed in which case the transaction would consist of multiple commands. Therefore when a transaction is present entity sets should not be invalidated immediately because if saving changes fails the transaction will be rolled back and the affected entity sets should not be invalidated. That's why the InvalidateSets method saves affected entity sets "for later" if a transaction is present. When a transaction is successfully completed EF will call the Committed method where the previously stored affected entity sets are invalidated.

Thanks,
Pawel