Caching and lazy loading

Hi,

In the blog post http://www.mindscapehq.com/blog/index.php/2009/11/05/whats-the-deal-with-lightspeed-caching/ it says that: 

To summarise when a cache hit would occur:

• You fetch an entity by Id
• You fetch a collection of entities
• You lazy load a collection or entity

Hi,

Cache hits do only occur when a FindById is done, however when a collection of items is loaded from the database, we do an internal check to see if each entity is already in the internal identity map (1st level cache). That way if you have an entity that is loaded, but is also part of a collection elsewhere you won't have two copies of the same entity with different properties.

If you lazy load an object (say, BlogPost has an AuthorId referencing an Author entity) and you requested the Author property, LightSpeed will first check if there is an Author entity with that AuthorId in the first level cache. If you're not seeing that please let me know as perhaps something is going wrong.

I'm re-reading that blog post, which I wrote quite some time back and I see why you're confused as it's not very clear what we're doing there. So you haven't misunderstood - I just didn't make it clear enough.

We don't load entire collections from the cache (e.g. a FindAll would not return from the cache, but we would check as we hydrated entities if they already existed in the 1st level cache). There has been some preliminary work done on trying to cache entire table's when needed and that is discussed here:

http://www.mindscapehq.com/forums/Thread.aspx?PostID=12949

Improving the overall caching strategy is something we're always looking at and we appreciate any requests you have.

I hope that helps.

John-Daniel

The reason i have been testing out how it works is that I've been attempting to impliment query level caching by add entities to the cache manually using UnitOfWork.Context.Cache.Add. That works fine and I can get them again from the cache and re attach them to the unit of wort using attach. 

The issue I'm having is that when I update an entity even though I'm calling remove before it seems to still use the cached version. So occasionally the entity won't change. Have you come across this? Is this the identity map coming into play?

It sounds like it.

The IdentityMap is distinct from the Level 2 cache (the .Cache property on the UnitOfWork.Context) and is internal to the UnitOfWork instance. Any entity which is loaded or attached will be held in the IdentityMap and any subsequent fetches of that entity will return the copy from the IdentityMap.

If you want to flush the IdentityMap you need to call UnitOfWork.SaveChanges(true).

Is there some code you can post showing what you are currently doing?

Jeremy

I can't really extract the code easily. I am changing two entities one of which was previously cached, although removed from the cache before the save. The one that was cached doesn't update. The entity state says modified but there is only one sql update statement instead of two. I've tried calling .SaveChanges(true) but it doesn't seem to make a difference. 

I'm not sure if it's a bug but here is what i do and here is what happens:

I clear the cache.

I get a "blog" entity  using a normal query from the unit of work. 

I get two post entites by using blog.Posts().FirstOrDefault(x => x.Id == id);

One of these has not been cached and one hasn't. 

I changes one property on both. They both show state as modified.

One update statement is produced by lightspeed. 

on closer inspection: 

When I step through both say they are modified but when I look at the unit of work collection the previously cached entity says it's state is default, the new one says modified. Odd! 

Is this a bug or am I doing it wrong?