If a single execution of an enterprise bean method requires more than one
request processor, your application could experience deadlock problems. (A
method can be said to “require more than one request processor” if
it calls one or more other, typically remote, methods, each of which must
execute in a different request processor.) Deadlocks can be caused by all
the request processors required to satisfy the method being forced to wait
for a JVM when no more JVMs are permitted. This can occur for two reasons:
- In the simple case, the maximum number of JVMs allowed to exist concurrently
under CICS (MAXJVMTCBS) is smaller than the number of request processors required
to service the method request.
- In the complex case:
- CICS is processing multiple requests simultaneously.
- All the requests are waiting for another JVM.
- All the permitted JVMs are currently in use.
Avoiding the simple case is easy; avoiding the complex case is more difficult.
It is necessary to ensure there are always enough free JVMs to allow at least
one method's requirement of request processor instances to be satisfied.
The maximum number of concurrent JVMs available to a bean method is set
by the MAXACTIVE attribute of the TRANCLASS definition for the request processor
transaction. The maximum number of concurrent JVMs available to CICS is set
by the MAXJVMTCBS system initialization parameter.
To remove the possibility of deadlocks caused by bean methods that use
multiple request processors:
- Wherever it is consistent with your applications' requirements, try
to minimize the number of request processors each method requires, preferably
to one. If you can reduce the requirements of all methods, in all applications,
to one request processor, you need do no more.
- If it is not possible to reduce the requirements of all methods to one
request processor, discover which is your “worst case”—that
is, the bean method that requires the most request processors in order to
be satisfied.
- Create a new TRANCLASS definition. This transaction class will apply to
the request processor transaction under which bean methods that require multiple
request processors will run.
- On the TRANCLASS definition, set the value of MAXACTIVE using the following
formula:
MAXACTIVE <= ((MAXJVMTCBS - n) / (n - 1)) + 1
where n is the maximum number of request processors required
by your “worst case” method.
If the result of this calculation
is a decimal value, round it down to the nearest (lower) whole number.
- Create new TRANSACTION and REQUESTMODEL definitions:
- Create a new TRANSACTION definition for the request processor transaction
under which bean methods that require multiple request processors will run.
(The easiest way to do this is to copy the definition of the default CIRP
request processor transaction and modify it.) On the TRANCLASS option, specify
the name of your new transaction class.
- Create one or more REQUESTMODEL definitions. Between them, your new REQUESTMODEL
definitions must cover all requests that may be received for bean methods
that require multiple request processors. On the TRANSID option of the REQUESTMODEL
definitions, specify the name of your new transaction.