See the WebSphere eXtreme Scale Wiki for links to eXtreme Scale Version 7.0 documentation.
If you log in
with your developerWorks ID, you can leave comments and feedback for the development team.
This topic describes various caching scenarios and terminology common to cache technologies.
ObjectGrid can be used in many different caching scenarios.
Near cache
Clients can optionally have a local, in-line cache when ObjectGrid is used in a client/server topology. This cache is called a near cache: It is an independent ObjectGrid that lives on each client, and is a cache for the remote, server-side core cache.
A near cache is very fast as it provides in-memory access to a subset of the entire cached data set stored remotely in the ObjectGrid servers. The near cache is not partitioned and contains data from any of the remote ObjectGrid partitions.
ObjectGrid can have up to three cache tiers:
- The transaction tier cache contains all changes for a single transaction. The transaction cache contains a working copy of the data until the transaction is committed. When a client transaction requests data from an ObjectMap, the transaction is checked first.
- The near cache in the client tier contains a subset of the data from the server tier. When the transaction tier does not have the data, the data is fetched from the near cache and inserted into the transaction cache.
- The core cache in the server tier contains the majority of the data and is shared among all clients. The server tier can be partitioned, which allows a large amount of data to be cached.
- When the client near cache does not have the data, it is fetched from the server tier and inserted into the client cache.
- The server tier can also have a Loader plug-in. When the server core cache does not have the requested data, the Loader is invoked and the resulting data is inserted into the server's core cache.
The near cache is enabled by default when locking is configured as optimistic or none and cannot be used when configured as pessimistic. To disable the near cache, set the numberOfBuckets attribute to 0 in the client override ObjectGrid descriptor configuration. See Map Entry Locking for details on ObjectGrid's lock strategies.
The near cache can also be configured to have a separate eviction policy and different plug-ins using a client override ObjectGrid descriptor configuration. See the topic: Configuring an ObjectGrid client for details.
Sparse and complete cache
ObjectGrid can be used as a sparse cache or a complete cache. A sparse cache only keeps a subset of the data and can be populated lazily, on-demand. Sparse caches are normally accessed using keys (instead of indexes or queries) since the data is only partially available. When a key is not present (a cache miss), the next tier is invoked and the data is fetched and inserted into the respective cache tier. If using a query or index, only the currently loaded values are accessed and the requests are not forwarded to the other tiers.
A complete cache contains all of the required data and can be accessed using non-key attributes using indexes or queries. A complete cache is preloaded with data prior to applications' using it. Once loaded, it can be treated similarly to a database. Since all of the data is there, queries and indexes can be used to find and aggregate data.
Side cache
ObjectGrid can be used as a side-cache for an application's data access layer. In this scenario, the ObjectGrid is used to temporarily store objects that would normally be retrieved from a back-end database. Applications check to see if the ObjectGrid contains the desired data. If the data is there, the data is returned to the caller. If the data is not there, the data is retrieved from the back-end and inserted into the ObjectGrid so that the next request can use the cached copy. See Using ObjectGrid with JPA for details on how JPA can be integrated with ObjectGrid.
The following diagram illustrates how ObjectGrid can be used as a side-cache using an arbitrary data access layer such as OpenJPA or Hibernate.
Side cache plug-ins for Hibernate and OpenJPA 
ObjectGrid version 6.1.0.3 includes cache plug-ins for both OpenJPA and Hibernate, which allow ObjectGrid to be used as an automatic side-cache. Using ObjectGrid as a cache provider increases performance when reading and querying data and reduces load to the database. ObjectGrid has advantages over built-in cache implementations because the cache is automatically replicated between all processes. When one client caches a value, all other clients will be able to utilize the cached value.
In-line cache
When used as a in-line cache, ObjectGrid interacts with the back-end using a Loader plug-in. This scenario can simplify data access by allowing applications to access the ObjectGrid APIs directly. ObjectGrid supports several different caching scenarios to make sure the data in the cache and the data in the back-end are synchronized.
ObjectGrid provides two JPA loader plug-ins that utilize Apache OpenJPA or Hibernate. These loaders can greatly simply database synchronization since all of the database interactions are handled automatically by the JPA provider.
The following diagram illustrates how an in-line cache interacts with the application and back end using a loader.
ObjectGrid supports several in-line caching scenarios:
- Read-through
- Write-through
- Write-behind
Read-through caching scenario
A read-through cache is a sparse cache that lazily loads data entries by key as they are requested. This is done without requiring the caller to know how the entries are populated. If the data cannot be found in ObjectGrid cache, ObjectGrid will retrieve the missing data from the Loader plug-in, which loads the data from the back-end database and inserts the data into the cache. Subsequent requests for the same data key will be found in the cache until it is removed, invalidated or evicted.
Write-through caching scenario
In a write-through cache, every write to the cache synchronously writes to the database using the Loader. This method provides consistency with the back-end, but decreases write performance since the database operation is synchronous. Since the cache and database are both updated, subsequent reads for the same data will be found in the cache, avoiding the database call. A write-through cache is often used in conjunction with a read-through cache.
Write-behind caching scenario
Database synchronization can be improved by writing changes asynchronously. This is known as a write-behind or write-back cache. Changes that would normally be written synchronously to the loader are instead buffered in the ObjectGrid and written to the database using a background thread. Write performance is significantly improved since the database operation is removed from the client transaction and the database writes can be compressed. Refer to Write-behind caching support for more details.
Database synchronization techniques
When ObjectGrid is used as a cache, applications must be written to tolerate stale data if the database can be updated independently from an ObjectGrid transaction. ObjectGrid provides several methods to keep the cache updated.
Periodic refresh
The cache can be automatically invalidated or updated periodically using the JPA time-based database updater. The updater will periodically query the database using a JPA provider for any updates or inserts that have occurred since the previous update. Any changes identified are automatically invalidated or updated when used with a sparse cache. If used with a complete cache, the entries can be discovered and inserted into the cache. Entries are never removed from the cache.
Eviction
Sparse caches can utilize eviction policies to automatically remove data from the cache without affecting the database. ObjectGrid includes three built-in policies: time-to-live, least-recently-used, and least-frequently-used. All three policies can optionally evict data more aggressively as memory becomes constrained by enabling the memory-based eviction option. See the Evictors topic for further details.
Event-based invalidation
Sparse and complete caches can be invalidated or updated using an event generator such as Java Message Service (JMS). Invalidation using JMS can be manually tied to any process that updates the back-end using a database trigger.
ObjectGrid provides a JMS ObjectGridEventListener plug-in that can notify clients when the server cache has any changes. This can decrease the amount of time the client can see stale data.
Programmatic invalidation
The ObjectGrid APIs allow manual interaction of the near and server cache using the Session.beginNoWriteThrough(), ObjectMap.invalidate() and EntityManager.invalidate() API methods. If a client or server process no longer needs a portion of the data, the invalidate methods can be used to remove data from the near or server cache.
The beginNoWriteThrough method applies any ObjectMap or EntityManager operation to the local cache without calling the loader. If invoked from a client, the operation applies only to the near cache (the remote loader is not invoked). If invoked on the server, the operation applies only to the server core cache without invoking the loader.
Additional information
© Copyright IBM Corporation 2007,2009. All Rights Reserved.
