Summary: GigaSpaces IMDG supports three different caching mechanisms: in-line cache, side cache and client cache.
OverviewThe GigaSpaces In-Memory DataGrid (IMDG) supports three types of caching mechanisms: in-line, side and client cache. Using GigaSpaces IMDG as a cache provides the following benefits:
The main supported caching mechanisms are the in-line cache and the side cache. Both the In-line cache and the Side cache support the common deployment toplogies: replicated, partitioned and primary-backup partitioned. The In-line Cache MechanismWith the In-line Cache mechanism, the IMDG is the system of record. The database data is loaded into the IMDG when it is started. The IMDG is responsible for loading data and pushing updates back into the database. The database can be updated synchronously or asynchronously.
The in-line cache is implemented using the following configurations:
Persistence logic can either be the out-of-the-box NHibernate external data source or any custom persistence logic that implements the external data source interfaces. The in-line cache ensures maximum performance when fetching data where the database is outside the critical path of the application transaction. (This makes more sense than it might seem: database contention is a primary source of application performance failure.)
When should you use an In-Line Cache?An in-line cache is very useful when:
The Side Cache MechanismWith the Side Cache mechanism, the application is responsible for maintaining the data in the cache. The Side Cache Mechanism is implemented as follows: 1. The application attempts to read an object from the cache.
4. The next time the application attempts to fetch the same object, it will be read from the cache, unless the object expired or was evicted. When should you use a side cache?A side cache is very useful when:
The Client CacheTogether with the in-line cache and side cache scenarios, you can also use client cache. This client cache may host data loaded from any IMDG partition. The client cache data access does not involve any serialization or network calls. When using client cache, a two-layered cache architecture is used: The first layer runs locally, within the client, and the second layer runs in the remote IMDG. The remote IMDG may use any of the supported deployment topologies. In-line cache with a client cache:Side cache with a client cache:The client cache size is limited to the client process heap size. The client-side cache is updated automaticaly once the master copy of the object within the IMDG is updated. The client cache can be implemented using the following configurations:
When should you use a Client Cache?The Client side cache should be used when most of the application activities (above 80%) involves reading data (a read-mostly scenario). When having repeated read activities for the same data (using ReadById operation), client cache provides an excellent performance boost (up to 100 times faster when compared to when a client cache is not being used). You should not use client cache when having a relatively large amount of data updates or removal operations since the overhead of the client cache updates will impact the overall application performance. Cache Refresh OptionsWhen running the cache in LRU cache policy mode, you may need to expire or evict the cache data. This will make sure you do not load the cache with unnecessary data. Another reason to expire or evict the cache data is to make sure the memory allocated for the cache (VM heap size) can accommodate the most valuable objects your applications needs. Options for refreshing the cache:
|
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |