Collection Caching

Re: Collection Caching, the Caching page mentions, "If you wish to cache an entire entity set in memory (e.g. for reference data) you can use FindAll caching. To apply this to an entity open the LightSpeed Model Explorer (View > Other Windows > LightSpeed Model) and in the tree view locate the entity that you want to cache. Right-click it and choose Add New Caching Options. Then expand the entity, select the Caching Options node, and you will see the option for Cache Find All Result in the Properties grid."

Is this basically an eager-loading/hydrating an entire entity load graph? Does FindAll have to be used?!

If, for example, I have a Person entity which has a collection of Address entities, are those Addresses all cached (or is this a normal cache feature and wouldn't require Collection Caching).

Another example. Let's say I have an entity called "Country" (arguably reference data that never changes) and I call something like:

List<Country> countries = uow.Countries;

Will that add all Countries into Level 2 cache on its first hit, loading from Level 2 cache on subsequent hits? Is Collection Caching necessary in this case?

FindAll caching saves the database call to load the entities only to find each one of them exists in the L1/L2 cache after processing the result. If you are dealing with reference data which you know is not going to change in the cache lifetime you would want to use collection caching to avoid any subsequent database calls.

Jeremy

So must I use ".FindAll"? And how is this different from :

List<Country> countries = uow.Countries;

adding to the L2 cache on access?

I guess I don't understand the point of Collection Caching if the above code would cache all Countries anyway...

At what point does the Collection Cache get populated?

Please let me know if the below is true?

In my example, with Collection Caching off:

1. uow.Countries will get all countries, and then insert each hydrated Country entity into the L2 cache.
2. Subsequent calls to uow.Countries WILL STILL query the database to retrieve the rows from the "Countries" table, but, will then hydrate each returned row from L2 cache.

With Collection Caching on:

1. uow.Countries will get all countries, and then insert each hydrated Country entity into the L2 cache. (Same as above)
2. Subsequent calls to uow.Countries will immediately check L2 cache for the entities since it's using Collection Cache?

It will avoid the database call if you call FindAll again.

With Collection Caching on:

1. uow.Countries will get all countries, and then insert each hydrated Country entity into the L2 cache. (Same as above)
2. Subsequent calls to uow.Countries will immediately check L2 cache for the entities since it's using Collection Cache?

Point 2 is incorrect, it will not immediate check for entities in the L2 cache since it doesnt know the set of entities to check for, so a database call will be made and on hydrating the entities the cache is checked for an existing instance first. Using the collection caching avoids this call as we cache the set itself to know who the members are.

Jeremy

I'm trying really hard to understand this... First you mention that "[With Collection Caching on] a database call will be made and on hydrating the entities the cache is checked for an existing instance first," but then your next sentence you mention, "Using the collection caching avoids this call."

Also, I need to know, must I use ".FindAll" or is uow.Countries equivalent?

I performed some more testing and something appears to be very wrong...

Setup: The "Property" and "LineItem" entities have Caching enabled.

Example 1 (Collection Caching Off, Caching Doesn't Seem To Be Working):

LineItem l1 = uow.LineItems.Where(a => a.Id == 326229).Single();
List<Property> p1 = l1.Properties.ToList();

LineItem l2 = uow.LineItems.Where(a => a.Id == 326231).Single();
List<Property> p2 = l2.Properties.ToList();

each uow.LineItems... call generates a database call, which I expect because it's technically a "query" and not a "FindById." However, on subsequent calls of this code, I expect the "Properties" of l1 and l2 to be fully hydrated, and pulled from cache instead of with database calls, which doesn't happen... database calls happen for each of the above 4 lines, during every execution (within the cache timeout).

I can see that all 4 items are added to the cache (Note, each LineItem has exactly one Property in the Property collection):

6/27/2014 3:41:56 PM Setting entity into cache [LineItem [Id=326229, EntityState=New]]

6/27/2014 3:41:58 PM Setting entity into cache [Property [Id=326230, EntityState=New]]

6/27/2014 3:42:06 PM Setting entity into cache [LineItem [Id=326231, EntityState=New]]

6/27/2014 3:42:08 PM Setting entity into cache [Property [Id=326232, EntityState=New]]

Therefore, it would seem that caching is not retrieving hydrated entities properly...

Setup: The "Property" and "LineItem" entities still have Caching enabled. "LineItem" now also has Collection Caching enabled.

Example 2 (Collection Caching Off, Caching Doesn't seem to be working, using the exact same code above):

LineItem l1 = uow.LineItems.Where(a => a.Id == 326229).Single();
List<Property> p1 = l1.Properties.ToList();

LineItem l2 = uow.LineItems.Where(a => a.Id == 326231).Single();
List<Property> p2 = l2.Properties.ToList();

In this example, each uow.LineItems... call generates a database call, which I still expect because it's technically a "query" and not a "FindById." However:

List<Property> p1 = l1.Properties.ToList();

performs a database call only on the first run and seems to populate the single Property for the LineItem (and retrieves p1 from cache for each additional call), however, LightSpeed seems to think a FindAll call has populated the entire Property collection, so when this line runs:

 List<Property> p2 = l2.Properties.ToList();

it DOES NOT perform a database call, AND p2 contains zero results (again, LightSpeed seems to be checking the FindAll Property cache and since it only contained one Property for l1, it returns zero results for p2.)

6/27/2014 3:53:20 PM Setting entity into cache [LineItem [Id=326231, EntityState=New]]

6/27/2014 3:53:24 PM Found 'find all' result in cache [Property]

Therefore, caching does not appear to be working, or I am using it improperly, but I expect already hydrated entities, known to be in cache, to be retrieved first. Additionally, Collection Caching dangerously omits the "All" part of "Find All" when initially populated.

Example 3: Even if I modify my code to use FindById:

LineItem l1 = uow.FindById<LineItem>(326229);
List<Property> p1 = l1.Properties.ToList();

LineItem l2 = uow.FindById<LineItem>(326231);
List<Property> p2 = l2.Properties.ToList();

The initial calls to uow.FindById... do perform a database query and populate the cache as expected, and all subsequent calls to the same code above DOES pull each LineItem from cache immediately, again, as expected, however, EVERY call for properties performs a database query... instead of loading the fully populated LineItem entities from cache (which should include fully populated collections of Properties)...

Per Caching,

as LightSpeed receives the result and looks to hydrate an entity it will first check if it already has an entity in the first level cache and ...

... The second level cache, if enabled, will also be checked in all of the same situations

This does not appear to be the case:

To summarise when a cache hit would occur:

· You fetch a collection of entities

Hi Bill,

I think the main issue in both of these examples is you are expecting the Properties collection on each LineItem which is being returned from the second level (L2) cache to be populated because when they were originally cached those collections were populated at the time - is that correct? If so the reason this is not occurring is that we dont cache the child collection information for entries in the L2 cache.

To expand on this Im assuming by cache in the examples you mean the L2 cache. With the L2 cache only the entity instance itself is cached and any child collections are marked as lazy so they will trigger a database call on the next access. If the collection of properties are known and are cached (so you can fetch them by Id) you can manually load the child collections which would avoid the DB call.

Im not clear from your examples if this is achievable or sensible but if it is you may want to load these manually. The best way to do this is by implementing a custom method on your entity class which allows you to assign a set of values into that collection. As a bit of background on this under the covers child collections are managed within a managed container called an EntityCollection (you will see an EntityCollection used for holding the children on your association). This in turn has a flag indicating if the collection is loaded. So ultimately what we want to do is indicate that the collection is already loaded prior to you accessing it via its standard collection property which would otherwise trigger a lazy load to occur. This flag is exposed but it needs to be accessed directly against the field on the entity itself as touching the collection would trigger a lazy load, so to do this we could set up a method such as:

// Assuming an entity LineItem which has an association to Properties
// The backing field for the collection is _properties

public partial class LineItem
{
  public void SetPropertiesCollection(IEnumerable<Property> properties)
  {
    if (!_properties.IsLazy)
    {
      throw new InvalidOperationException("This is only valid prior to the collection being loaded");
    }

    _properties.IsLazy = false; // This sets the collection to indicate it has been loaded
    _properties.AddRange(properties); // This assigns a set of objects into the collection, e.g. your manual set
  }
}

I wanted to also re-iterate about FindAll caching as I suspect there may be a misconception here about how it works; FindAll caching caches the set of entities returned from a UnitOfWork.Find() or uow.TEntities.ToList() call so that a subsequent call of the same type returns the same result and avoids the database call. It is not used for any child collection caching or for caching results involving a query.

Jeremy