Cache

Who made this query so fast? Mr. Cache

Any application that relies in a RDBMS is limited by the database server. The fever queries (or the the simpler they are) the better.

In many applications, there are tables that are read frequently but are rarely modified, we call this tables master data (e.g., Products). Other tables are written much more often, those are call transactional data (e.g., Orders).

Transparent Cache

Cache module is able to store any master data table for into memory. When the engine needs to retrieve any entity in this tables, 0 queries are necessary.

Additionally, when there are complex object graphs of transactional data referring to master data  (e.g., Orders have Products) the queries can be dramatically simplified by retrieving all the master data from memory instead.

For the client code, the Cache sub-module is undetectable. They get a fresh new entity instance on each retrieve, just faster, so no code changes are necessary. This means that you can experiment catching some tables without affecting the rest of the system.

The in-memory tables are automatically invalidated using Sql Server Service Broker when the current application server, or any other one, changes the master data in the database. This enables farms of application servers.

In the rare situations where master data refers to transactional data (e.g., Products is master data but refers to a Company that is transactional), the cache module is able to cache (and invalidate depending on) only the related transactional data (e.g., cache only the Companies referred by Products).

Shared Data Structures

When some data is accessed frequently, like product catalogs, it makes sense to have a shared read-only data structure. This way not even entity incantations are necessary, being even faster.

The cache module will also let you invalidate this shared data structures easily in a multi-server scenario using Service Broker.

This data structures will be lazily retrieved when used, but they will be loaded in a special, global context, so won't be affected by the transaction or the authorization rules of the user who triggered the cache load. 

Any arbitrary data structure can be stored in this kind of caches (e.g., lists, dictionaries, hash sets). Since this data structures are shared in a multi-thread server, if this data structures contain entities, they are marked as Sealed avoiding any kind of modification.

Partial Invalidation

The cache module promotes a simple all-or-nothing strategy caching tables, due to the strong limitations of SqlDependency.

If you have a big amount of master-like data that gets gradually out-dated (e.g., events, promotions, news...), contact us and we will help you on writing this kind of cache with the tools provided by the module.