WebSphere® Application Server for z/OS
® uses
global resource serialization (GRS) to communicate information between
servers in a sysplex. When there are multiple servers defined in a
system or a sysplex, a request might end up on the wrong server. To
determine where the transaction is running,
WebSphere Application Server uses GRS. Therefore,
if you are using global transactions,
WebSphere Application Server will issue an
enqueue for that transaction at the start of the transaction and hold
on to that enqueue until the transaction ends.
WebSphere Application Server for z/OS uses
GRS enqueues for the following:
- Two-phase commit transactions involving more than one server
- HTTP sessions in memory
- Stateful EJBs
- "Sticky" transactions to keep track of pseudo-conversational states.
- If you are not in a sysplex, you should configure GRS=NONE.
- If you are in a sysplex, you should configure GRS=STAR.
This requires configuring GRS to use the coupling facility. All
of the WebSphere Application Server enqueues
are issued with RNL=NO, which prevents misconfiguring the GRSRNLxx
with inappropriate values. See the GRS documentation for details on
setting this up.
Avoid trouble: If you are using a GRS ring to attach one or more monoplexes to a sysplex environment,
the cell name of any servers running in any of the monoplexes must
be unique within the entire GRS environment. This requirement means
that the cell name of a server running in any of the monoplexes:
- Must be different than the cell name of any servers running in
the sysplex
- Must be different than the cell name of any servers running in
another monoplex that is attached to the sysplex
If you have servers with duplicate cell names within the GRS
environment, WebSphere Application Server cannot differentiate between
the sysplex cell and the monoplex cell, and treats both servers as
part of the same cell, This inaccurate cell association typically
causes unpredictable processing results.
gotcha