Distributed Cache Capabilities - Data Integrity

Capability

Description

Weight

Transaction support

A cache that supports transactions will allow grouping actions and committing them at the same time. Usually the cache can be enlisted as a distributed transaction under technologies like DTC. The cache will provide BEGIN, COMMIT and ROLLBACK functionality. Usually this feature is implemented using a separate transaction log.

3

Guideline

The designer needs to consider if  this feature is needed, first, this feature is usually quite expensive, not  only on cache price tag but in performance. A designer should ask itself if a  database will not be able to provide the functionality that requires, as they  are transaction aware by design. If this feature is needed then try to avoid  deadlock situations as cache servers are not very good detecting them when  working in a very high distributed environment. We will recommend to analyze  other options and if a transactional cache is needed do perform exhaustive  testing.

Capability

Description

Weight

Multi-threading support

A multi thread environment aware  cache will allow separate threads to access the same cache item without  entering in race conditions while writing the item. Usually this capability  implements an internal lock over the item only (note that some caches may use  a table or region lock). Certain caches will also offer a capability to lock  several cache items at the same time.

5

Guideline

This is simple, if a cache does  not provide proper multithreading support just don’t buy it. Is within the  nature of distributed caches to support multiple connections accessing the  same information and if it does not support it then is not worth the  investment.

Capability

Description

Weight

External dependencies

This capability allows cache  items to have external cache items dependencies, for example files. This  allows cache items to be either backed up or extended through a connection to  an external source. Quick recovery caches use this technique to recover from  faults.

2

Guideline

This feature has been very useful  in the past, when 32 bits processes where running out memory pretty fast.  Designers have implemented a secondary storage, for example a file to  optimize the cache (using the cache as an index entry).  With the new 64 bits cache the memory can  be plentiful but still consider this feature if you need to allocate large  amount of data in the cache (for example photos, maps, videos).

Capability

Description

Weight

SQL Server synchronization

A cache may allow a cache item,  cache region or table to be synchronized with a SQL Server database. This  will mirror each entry to a database entry. This back up repository is  usually accessed when a fault occurs or when a database item has changed and  the cache needs to reflect the changes (instead of evicting the item).

3

Guideline

Losing a cache can be a big event  in certain scenarios or if the system may be accessed by other systems that  are not cache aware then a SQL dependency can be very helpful. We have seem  dozen of scenarios where the data is replicated from a another location, i.e.  a call center, and the data in the cache needs to be modified to stay  current. There is a performance implication but experience says that is a  very useful feature if those scenarios are considered.

Capability

Description

Weight

Oracle Synchronization

A cache may allow a cache item,  cache region or table to be synchronized with an Oracle database. This will  mirror each entry to a database entry. This back up repository is usually  accessed when a fault occurs or when a database item has changed and the  cache needs to reflect the changes (instead of evicting the item).

3

Guideline

Same guideline as above, in this  case if your data is going to be supported by Oracle.

Capability

Description

Weight

Other DB synchronization

A cache may allow a cache item,  cache region or table to be synchronized with other vendors database (i.e.  Informix, Ingress, DB2 no name a few). This will mirror each entry to a  database entry. This back up repository is usually accessed when a fault  occurs or when a database item has changed and the cache needs to reflect the  changes (instead of evicting the item).

3

Guideline

Same guideline as the SQL  dependency but in this case consider caches with heterogeneous data models if  you have scenarios with multiple database technologies utilization, therefore  use it only when needed. Having individual gets on the hand will require a  separate call per retrieval, affecting the network and cache performance.