This project is read-only.

Entity Framework (EF) 2nd Level Cache Provider

Here is Julie Lerman's article on EF 2nd Level Caching:

Scalable Cache Provider

This is a 2nd level "scalable" caching provider for EF. The solution uses SOP framework as database engine for persisting entities and dependent entity sets submitted to this module by the application via the EF provider module stack.


EF 2nd level caching requires a high speed data persistence engine. High speed, efficient, scalable, low-footprint, those are the requirements. It will not offer any much benefit, if at all a solution will, if the cache provider will not be able to fit these requirements, 'might as well not do 2nd level caching at all.
If the caching provider will utilize the same or similar in performance solution with EF's data persistence, the benefits to the application will not be that significant if there will be. It will actually be slower as the caching provider will double the amount of time required to do data I/O.

Imagine using EF for implementing the 2nd level cache, the act of persisting the cached data will have its own needs to be cached, who will provide caching for this additional level?
Similarly, imagine implementing 2nd level caching using traditional ADO.Net & MySQL/SQL Express solution, 'given this setup, the caching layer will be bounded by the limits of ADO.Net & MySQL/SQL Express persistence performance, factor in the latency of flowing the data between this caching layer and EF, i.e. - the data translation/serialization, inter-process communication as DB engine is normally out of the application process, and other house keeping functionalities on each, we are looking at a solution that can barely increase performance, may not be significant enough as a 2nd level caching provider. Much worse performance output, if we are looking for a solution that requires more bandwidth or latencies in flowing the data.

At best, EF 2nd level cache provider needs to approach in-memory caching performance. However, RAM is a limited resource, it can only accomodate so much amount of cached data.

Here is where SOP comes in, since SOP's data Store performance proximates in-memory dictionary performance in lookup and item management, only additional latency is during bulk I/O to disk during heavy data load times where not all data can fit in-memory, which also, can be alleviated by setting up a high performance HDD RAID drives, then an EF 2nd level caching provider using SOP seems to offer the best/optimal solution to date.

EF 2nd Level Caching Provider via SOP

EF 2nd Level Caching Provider is an application "in-process" implementation. I.e. - it is a module that directly make calls to SOP library (has option to do background, threaded disk mapping), which provides application level Object caching. Application level, meaning, the data flowed from EF provider "stack" are cached within the same application hosting the EF caching provider module set, as a managed code using .Net dictionary and/or SOP's in-memory B-Tree dictionary. Latency has been kept to the bare minimal, no inter-process communication, no serialization/translation across layer bottlenecks, no managed to unmanaged memory "pinning" latency, etc...

<Provider discussion goes here>

(under construction, more to follow...)

Last edited Sep 5, 2012 at 8:16 AM by grecinto, version 11


No comments yet.