InfoCenter Home >
7: Multimachine management >
7.1: Using WebSphere Application Server in a multimachine environment >
7.1.6: Managing state
7.1.6: Managing state
Multimachine scaling techniques rely on using multiple copies of an application server;
multiple consecutive requests from various clients can be serviced by different servers.
If each client request is completely independent of every other client request, it does
not matter whether consecutive requests are processed on the same server. However, in
practice, client requests are not independent. A client often makes a request, waits for
the result, then makes one or more subsequent requests that depend on the results received
from the earlier requests. This sequence of operations on behalf of a client falls into
two categories:
- Stateless: A server processes requests based solely on information
provided with each request and does not reply on information from earlier requests. In
other words, the server does not need to maintain state information between requests.
- Stateful: A server processes requests based on both the information
provided with each request and information stored from earlier requests. In other words,
the server needs to access and maintain state information generated during the processing
of an earlier request.
For stateless interactions, it does not matter whether different requests are processed
by different servers. However, for stateful interactions, the server that processes a
request needs access to the state information necessary to service that request. Either
the same server can process all requests that are associated with the same state
information, or the state information can be shared by all servers that require it. In the
latter case, accessing the shared state information from the same server minimizes the
processing overhead associated with accessing the shared state information from multiple
servers.
The load distribution facilities in WebSphere Application Server make use of several
different techniques for maintaining state information between client requests:
- Session affinity, where the load distribution facility recognizes the
the existence of a client session and attempts to direct all requests within that session
to the same server.
- Transaction affinity, where the load distribution facility recognizes
the existence of a transaction and attempts to direct all requests within the scope of
that transaction to the same server.
- Server affinity, where the load distribution facility recognizes that
although multiple servers might be acceptable for a given client requests, a particular
server is best suited for processing that request.
The WebSphere Session Manager, which is part of each application server, stores client
session information and takes session affinity and server affinity into account when
directing client requests to the clones of an application server. The workload management
service takes server affinity and transaction affinity into account when directing client
requests among the clones of an application server.
|
Related topics |
|
| Home (Getting started page) |
|
Sub-topics |
|
| 7.1.6.1: HTTP sessions, servlets, and the session manager |
|
| 7.1.6.2: EJB sessions and transaction affinity |
|
| 7.1.6.3: Server affinity |
|
Peer topics |
|
| 7.1.1: Scaling up WebSphere applications |
|
| 7.1.2: Availability management |
|
| 7.1.3: Multimachine topologies |
|
| 7.1.4: Firewalls and demilitarized zone (DMZ) configurations |
|
| 7.1.5: Remote database access with DB2 Universal Database (UDB) |
|
InfoCenter |
|
To launch the full documentation set in a separate browser window, click: |
| Display InfoCenter |
| |
PDF library |
|
To browse the PDF library for this product, containing this article and others, click: |
| PDF versions |
| |
Using this documentation |
|
Become an InfoCenter super user! To find out more about navigation, numbering, search, downloads, and more, click: |
| Using this documentation |
| |
|