Distributed Cache Capabilities - Data Integrity
Data expiration contains elements that make the cache allocation more efficient. The feature removes items that are not current from the cache, freeing the memory and the resources associated.
|
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. |
|
Original Post by Salvador Patuel on Decemeber 3rd, 2011