WebSphere for z/OS uses GRS to communicate information between
servers in a sysplex. When there are multiple servers defined in a
system or a sysplex, a request may end up on the wrong server. To
determine where the transaction is running WebSphere uses GRS. Therefore,
if you are using global transactions, WebSphere will issue an enqueue
for that transaction at the start of the transaction and hold on to
that enqueue until the transaction ends. WebSphere 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, we strongly recommend GRS=STAR.
This requires configuring GRS to use the coupling facility. All
of the WebSphere 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