WebSphere® eXtreme Scale is most
often used as a shared cache, to provide transactional access to data
to multiple components where a traditional database would otherwise
be used. The shared cache eliminates the need configure a database.
Coherency of the cache
The cache is coherent
because all of the clients see the same data in the cache. Each piece
of data is stored on exactly one server in the cache, preventing wasteful
copies of records that could potentially contain different versions
of the data. A coherent cache can also hold more data as more servers
are added to the data grid, and scales linearly as the grid grows
in size. Because clients access data from this data grid with remote
procedural calls, it can also be known as a remote cache, or far cache.
Through data partitioning, each process holds a unique subset of the
total data set. Larger data grids can both hold more data and service
more requests for that data. Coherency also eliminates the need to
push invalidation data around the data grid because no stale data
exists. The coherent cache only holds the latest copy of each piece
of data.
If you are running a
WebSphere Application Server environment,
the TranPropListener plug-in is also available. The TranPropListener
plug-in uses the high availability component (HA Manager) of
WebSphere Application Server to propagate
the changes to each peer ObjectGrid cache instance.
Figure 1. Distributed
cache
Near cache
Clients can optionally have a
local, in-line cache when
eXtreme Scale is
used in a distributed topology. This optional cache is called a near
cache, an independent ObjectGrid on each client, serving as a cache
for the remote, server-side cache. The near cache is enabled by default
when locking is configured as optimistic or none and cannot be used
when configured as pessimistic.
A near cache is very fast
because it provides in-memory
access to a subset of the entire cached data set that is stored remotely
in the
eXtreme Scale servers.
The near cache is not partitioned and contains data from any of the
remote
eXtreme Scale partitions.
WebSphere eXtreme Scale can have up to three
cache tiers as follows.
- 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 client tier, if available and inserted
into the transaction cache
- The data grid 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 data grid does not have the requested data,
the Loader is invoked and the resulting data is inserted from the
backend data store into the grid.
To disable the near
cache, see Configuring the near cache.
Advantage
- Fast response time because
all access to the data is local. Looking
for the data in the near cache first saves a trip to the grid of servers,
thus making even the remote data locally accessible.
Disadvantages
- Increases duration of stale
data because the near cache at each
tier may be out of synch with the current data in the data grid.
- Relies on an evictor to invalidate data to avoid running out of
memory.
When to use
Use when response
time is important
and stale data can be tolerated.