In the simplest case, WebSphere® eXtreme Scale can be
used as a local (non-distributed) in-memory data grid cache. The local
case can especially benefit high-concurrency applications where multiple
threads need to access and modify transient data. The data kept in
a local data grid can be indexed and retrieved using queries. Queries
help you to work with large in memory data sets. The support provided
with the Java™ virtual
machine (JVM), although
it is ready to use, has a limited data structure.
The local in-memory
cache topology for WebSphere eXtreme Scale is used
to provide consistent, transactional access to temporary data within
a single Java virtual machine.
Figure 1. Local in-memory cache scenario
Advantages
- Simple setup: An ObjectGrid
can be created programmatically or
declaratively with the ObjectGrid deployment descriptor XML file or
with other frameworks such as Spring.
- Fast: Each BackingMap
can be independently tuned for optimal
memory utilization and concurrency.
- Ideal for single-Java
virtual machine topologies with small dataset
or for caching frequently accessed data.
- Transactional. BackingMap
updates can be grouped into a single
unit of work and can be integrated as a last participant in 2-phase
transactions such as Java Transaction
Architecture (JTA) transactions.
Disadvantages
- Not fault tolerant.
- The data
is not replicated. In-memory caches are best for read-only
reference data.
- Not scalable. The amount of memory required
by the database might
overwhelm the Java virtual machine.
- Problems occur when adding Java virtual
machines:
- Data cannot easily be partitioned
- Must manually
replicate state between Java virtual machines or each cache instance
could have different versions of the same data.
- Invalidation
is expensive.
- Each cache must be warmed up independently.
The warm-up is the
period of loading a set of data so that the cache gets populated with
valid data.
When
to use
The local, in-memory cache deployment
topology should only be used when the amount of data to be cached
is small (can fit into a single Java virtual
machine) and is relatively stable. Stale data must be tolerated with
this approach. Using evictors to keep most frequently or recently
used data in the cache can help keep the cache size low and increase
relevance of the data.