Tuning for enterprise beans

If you are using enterprise beans in your CICS® system, this tuning information might help:

Customizing DFHEJOS for your anticipated stateful enterprise bean usage

The EJB Object Store, DFHEJOS, is a file used to store stateful session beans that have been passivated. It can be a VSAM file or a coupling facility data table. CICS supplies sample JCL to help you create this file, in the DFHDEFDS member of the SDFHINST library.

The CICS-supplied settings for DFHEJOS are designed for storage of a low number of objects (passivated beans), with a maximum size of 8K, to minimize storage wastage. If you anticipate heavy usage of stateful enterprise beans, increase the space allocations and record sizes for this data set.

The CICS System Definition Guide describes how to create DFHEJOS. To work out appropriate settings for the record sizes, follow the procedure described in "Determining the object store space requirements".

Enterprise beans that are involved in client-controlled OTS (object transaction service) transactions

The use of client-controlled OTS (object transaction service) transactions can affect your JVM requirements.

The typical enterprise bean workload in CICS begins with an incoming IIOP message, containing a GIOP request that is received by an IIOP listener task in CICS. The request is passed to a request receiver task, that examines the GIOP message and passes processing of the message to a request processor task. Finally, on completion of the request processor task, a response is sent back to the requesting client by the request receiver task.

If the GIOP request forms part of a client-controlled OTS transaction, then the request processor and request receiver tasks are not ended until the OTS transaction is committed or rolled back. Because the request processor task is executing in a JVM, that JVM is not available for any other task to use until the OTS transaction has ended. If this happens frequently, you might need to increase the number of JVMs in your JVM pool to avoid excessive waiting times for incoming requests.

Enterprise bean methods that require multiple request processors

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:

  1. 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.
  2. In the complex case:

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 that applies to 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

  5. Create new TRANSACTION and REQUESTMODEL definitions:
    1. 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.
    2. 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.

Related tasks
Defining EJB directory and object store data sets (DFHEJOS)Java applications using a Java virtual machine (JVM): improving performance
Tuning storage for individual JVMs
Tuning Language Environment enclave storage for JVMs
Tuning the z/OS shared library region
Managing your JVM pool for performance
Managing your JVMs
[[ Contents Previous Page | Next Page Index ]]