Summary: GigaSpaces IMDG supports three different caching mechanisms: In-line Cache, Side Cache and Client Side Cache.
OverviewGigaSpaces IMDG supports three kinds of caching mechanisms:In-line Cache, Side Cache and Client Side Cache. Using GigaSpaces IMDG as a cache provides you the following benefits:
Both the In-line cache and the Side cache support the common deployment toplogies: replicated, partitioned and primary-backup partitioned. In-line CacheWith this 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 the data and pushing updates back into the database. The database can be updated in synchronously or asynchronously.
The in-line cache is implemented using the following configurations:
Persistence logic can either be the out-of-the-box Hibernate external data source or any custom persistence logic that implements the Space Persistency extension points. 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.)
The in-line cache mechanism is widely used with the following GigaSpaces APIs:
When you should use an in-line cache?An in-line cache is very useful when:
Side CacheWith this mechanism, the application is responsible for maintaining the data in the cache: Side cache without External Data Source: Side cache with External Data Source: With a Side Cache architecture there is no Mirror. The application responsible to write changes to the database. Data is evicted or expired from the space by writing it with a finite lease (TTL). There are two options how data is loaded into the space:
The Side cache scenario is widely used with the following GigaSpaces APIs:
When you should use a side cache?A side cache is very useful when:
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, you use a two-layered cache architecture: 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:Side cache using External Data Source 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 you should use a Client Cache?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 will provide 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 will 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 (JVM heap size) can accommodate the most valuable objects your applications needs. Here are few options you may use to refresh the cache:
Refresh data using LRU and TimerWith this approach data is pushed into the cache in a periodic manner via a timer. The Timer will be fetching relevant data that was recently updated within the database and pushing it into the cache. Refresh data using a QueueAny updates made to the database are also written to a queue. Refresher client consumes the messages on the queue and applies these changes to space. Refresh data using Database Change NotificationsOracle and few other databases support Database Change Notifications where a client can register a listener for changes to data. Any changes made to the database will trigger the listener defined in a DCN Client. Listener can in turn write these messages into the space. |
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |