Summary: GigaSpaces IMDG supports three different caching mechanisms: in-line cache, side cache and client cache.

Overview

The 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:

  • Low latency: In-Memory Data access time without any disk usage.
  • Data access layer elasticity: Scale out/up on demand to leverage additional machine resources.
  • Less load on the database layer: Since the cache isolates the database from the application somewhat, there is less contention generated at the database layer.
  • Continuous High-Availability: Zero downtime of your data access layer with the ability to survive system failures without any data loss.

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 Mechanism

With 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.

  • When running in ALL-IN-CACHE cache policy mode, all data is loaded from the database into the cache once it is started.
  • When running in LRU cache policy mode, a subset of the data is loaded from the database into the cache when it is started. Data is evicted from the cache based on available memory or a maximum amount of cache objects. When there is a cache miss, the cache looks for the data within the underlying data-source. If matching data is found, it is loaded into the cache and delivered to the application.

The in-line cache is implemented using the following configurations:

  • Read-through and Write-through: For persisting the cache data synchronously.
  • Write-behind or Mirror: For persisting the cache data asynchronously.

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.)

For best performance use the ALL-IN-CACHE cache policy with the write-behind mirror. This will ensure maximum hit rates when accessing the cache. With this mode, make sure the cache can accommodate all the data you access.

When should you use an In-Line Cache?

An in-line cache is very useful when:

  • The total size of data stored within the database (or any other external data source) is equal or less than the amount of data stored in memory. Ideally, use the ALL_IN_CACHE cache policy mode.
  • The original data model of the data within the database (or any other external data source) is similar to the data model of the objects in memory. The external data source is very efficient, as the data is loaded automatically from the database into the cache and every change to the data in the cache is propagated to the database behind the scenes.

The Side Cache Mechanism

With 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.
2. If the object is found within the cache, the application uses it.
3. If the object isn't found within the cache:

  • The application fetches it from the database.
  • The application writes it into 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 total amount of data stored in the database (or any other external data source) is relatively much higher than the amount of data stored in-memory. In such a case, use the LRU cache policy mode.
  • The original data model of the data within the database (or any other external data source) is very different than the data model of the objects in-memory. In such a case the built-in External Data Source may not work well, but customized mapping logic should be implemented at the client application side to load data from the database and push it into the cache.

The Client Cache

Together 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:

  • Local Cache: On-demand client cache loading data based on client activity. This type of client cache evicts data once the client available memory drops below a configurable value.
  • Local View: Pre-fetch client cache loading data based on set of SQL queries. This client cache does not evict data. This client cache is designed to be read-only and support both queries and reads based on ID.
Client cache is not enabled by default.

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 Options

When 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:

  • Eviction: Configure the space to evict data by running in LRU eviction policy.
  • Lease expiration: Write objects into the space with a specific time to live (lease duration).
  • Programmatic expiration: An object can be expired using:
    • ILease.Cancel(): The Lease object can be returned as a result of a write operation for a new object.
    • ISpaceProxy.Write operation for an existing object (update) using a short lease time. See the ISpaceProxy interface interface write operation for details.
    • Take operation with TakeModifiers.EvictOnly mode. See the ISpaceProxy interface take operation for details.
  • Periodic refresh: Data can be periodically pushed into the cache using a timer. The Timer fetches relevant data that was recently updated within the database and pushes it into the cache.
  • Refresh data using a Queue: Any 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.
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence