Is there a conflict when using Data Caching and Lazy loading?

Question

If I plan to use data caching do I have to worry about conflicts when also using deferred loading? It seems that with linq i am losing control of my data.

Answer 1

Both LinqToSql and EntityFramework provide both features (deferred loading and data caching).

For example, if you initially load a Customer, that Customer will be cached and if you ask for it again you'll get the same instance.

If you don't load a Customer's Orders during that initial load, then the Orders property of that Customer instance will be in an unloaded state. When you do load those orders, then the Order instances will be available through that property.

• LinqToSql will load the property the first time it is used.
• EntityFramework will load the property when it is asked to do so (using the Load method).

In both technologies, the Context is the thing that does the caching... so if you use more than one Context instance - you could observe different Customer instances that really represent the same Customer.

---

Addressing your questions in comments. I'll be talking LinqToSql, but this stuff should work in EntityFramework as well.

• Here's an explanation of deferred vs immediate loading.
• Here's an explanation of object identity and caching.

if i shut off deferred loading i take it the data caching will still work?

Yes, that will work. However, they are not totally independent.

• Here's how to turn off caching (it's on by default).
• Here's how to turn of deferred loading (it's on by default). Read this one, since it explains how these features interact.

is data cache flushing dependent on whether there are changes in datatable and or time?

There is no flushing or resetting the cache. If you want a fresh cache, the thing to do is to create a new DataContext. Each instance of DataContext has its own cache.

• There is a way to pull update the cache with changes in the database aka - Refresh.
• There is no way to push changes from the database to the cache.