When an application requests execution of a Java™ program, CICS® first tries to find a suitable JVM that is available for reuse in the JVM pool. An application can reuse an available JVM if the JVM was created using the JVM profile and the execution key (USER or CICS) that are specified in the Java program's PROGRAM resource definition. If a suitable JVM is available, CICS assigns the JVM to the request.
If a suitable JVM, with the correct JVM profile and execution key, is not available, and the limit set by the MAXJVMTCBS system initialization parameter has not yet been reached, and MVS storage is not severely constrained, CICS creates a new JVM for the Java program. The new JVM has the correct profile and execution key for the program.
Figure 1 shows this process happening. Our example JVM pool is in the state shown above in Figure 1, with a MAXJVMTCBS limit of 5, and 5 JVMs in the pool. CICS receives two of the requests described above in Figure 1.
Request B specifies the PROGRAM resource definition for the default request processor program DFJIIRP, which names the JVM profile DFHJVMCD, and the execution key USER. CICS checks the JVM pool, and finds that JVM 3 has the correct JVM profile and execution key to match the request, and it is available for reuse. CICS assigns JVM 3 to Request B.
Request D specifies the PROGRAM resource definition for PROG1, which names the JVM profile USERJVM2, and the execution key CICS. CICS checks the JVM pool. There is a free JVM, JVM 2, but it has the wrong profile and execution key for Request D. As the MAXJVMTCBS limit has been reached, CICS cannot create a new JVM for Request D. So CICS must use the selection mechanism to decide if it should destroy JVM 2 and its TCB, and replace it with a JVM and TCB that matches Request D; or if it should make Request D wait, and keep JVM 2 for a request that can benefit more from it. If Request D is made to wait, it is queued along with any other requests that are waiting for a JVM.