WebSphere eXtreme Scale Best Practices for Operation and Management

4 WebSphere eXtreme Scale Best Practices for Operation and Management

1.3 Common usage patterns for WebSphere eXtreme Scale

The following usage patterns are common for WebSphere eXtreme Scale:

򐂰 Side cache

򐂰 Inline cache

򐂰 Application state store

򐂰 eXtreme Transaction Processing (XTP) or simply a data grid

Table 1-1 summarizes these usage patterns.

Table 1-1 Summary of WebSphere eXtreme Scale usage patterns

Context Problem Pattern or Solution Results

The application

is coded to

read data from

the database

The disk I/O is an

expensive operation.

When the workload is up,

we encounter slow

response time due to the

large number of disk I/Os

to retrieve data from the

back-end database.

Side cache:

A cache is normally a component

in memory to store data. When an

application needs data, it will look

for data in the cache first. If the

data is in the cache (cache hit),

the data is simply returned to the

application. If the data is not in the

cache (cache miss), the data is

retrieved from the back-end

database and added into cache.

The application talks to both the

side cache and the database.

򐂰 Reduced response time: The

more requests can be served

from the cache, the faster the

overall system performance

is.

򐂰 Reduced load on database.

Off-load redundant

processing.

򐂰 Can be used as:

– Hibernate/OpenJPA L2

cache

– Dynamic Cache service

provider

– Service-oriented

architecture (SOA) state

store

– SOA result cache

Chapter 1. Introduction to WebSphere eXtreme Scale 5

The application

is coded to

read data from

and write data

to the database

Write operations are

normally slower than

read operations when

accessing a database.

When there are many

create, update, or delete

transactions in the

application, writing to the

database becomes the

bottleneck of the whole

system.

Inline cache:

When an application needs data,

it interacts only with the inline

cache. The cache has a loader to

move the data between the cache

and the back-end database.

There are three scenarios with

inline cache: read-through,

write-through, and write behind:

򐂰 A read-through cache is a

read-only sparse cache that

lazily loads data entries by

key as they are requested,

without requiring the caller to

know how the entries are

populated.

򐂰 With a write-through cache,

you have the read-through

behavior, but for writes, the

transaction does not

complete until the data is

written to the backing store.

򐂰 With a write-behind cache,

the transaction completes

when the data is written to the

cache. The cache uses

replication to keep the data

available until it is written to

the backing store.

򐂰 Loaders used to integrate

with an existing back-end

database

򐂰 Read through reads at cache

speed if the data is already in

cache

򐂰 Write through write operation

to the cache is not complete

until the data is synchronized

to back-end database

򐂰 Write-behind pushes changes

asynchronously from cache to

back-end database

򐂰 Reduced load on database

Application

state needs to

be replicated

across multiple

systems and

some times

even multiple

data centers

Application state can be

a lot of things, including

business data, events,

tables, maps, images,

session information, and

much more. When the

user base increases, so

does the memory

consumption to store the

state. You might reach a

point where you cannot

allocate more system

resources to keep up

with the growing number

of concurrent users.

Application state store:

An application state store

provides large in-memory data

grids. This pattern is similar to the

inline cache usage pattern.

Where the inline cache is focused

on the database, this pattern is

geared toward a large, general

data-in-memory store. Application

state store can be used for:

򐂰 HTTP session store

򐂰 Application session store

򐂰 Multiple data center support

for sessions

򐂰 Memory provides faster

access times and increased

throughput compared to disk

and database stores

򐂰 Reduced response time and

increased throughput data in

memory

򐂰 Replication across the grid

provides high availability

򐂰 Write-behind allows for more

persistent store when

required

Moving state replication off the

database reduces the load on

database.

Context Problem Pattern or Solution Results