Continuous JVMs (REUSE=YES)

The continuous JVM is kept in the JVM pool for reuse. It is initialized once, and is reused many times, but it is not reset after each Java program has completed. A continuous JVM has the option REUSE=YES in its JVM profile.

Compared to the resettable JVM, the continuous JVM has a greater transaction throughput and lower CPU usage, because it is not performing a reset. The behavior of the continuous JVM is also more consistent with the behavior of JVMs on platforms other than CICS, which can be an advantage when executing Java programs designed for use in a generic reusable Java environment.

Programs that run in a continuous JVM are fully isolated from concurrent activity elsewhere in CICS. However, because there is no JVM reset after each Java program, the application code that runs in the next Java program or transaction is not isolated from the actions of the previous program invocation. Because of this, you can create persistent items that might be of use to future executions of the same application in the same JVM. (In a resettable JVM, this is not possible.) You do need to ensure that programs do not change the state of a continuous JVM in undesirable ways, or leave any unwanted state in the JVM.

Both middleware classes and application classes are permitted to perform actions in a continuous JVM which would cause a resettable JVM to be marked unresettable and destroyed. The application classes are trusted to reset themselves as required between transactions, and the JVM is not destroyed after use if these events take place. Resettable JVMs (REUSE=RESET) explains how a resettable JVM deals with unresettable actions.

A continuous JVM maintains the content of its storage heaps between one program invocation and the next. Storage heaps in a JVM explains the storage heaps that the JVM uses for different categories of objects. Static or dynamic state persist in a continuous JVM's storage heaps, and threads that are not quiesced will persist, along with their related storage. Shareable application classes are not reinitialized, and nonshareable application classes are kept intact, instead of being discarded and reloaded. The application can choose to clean up any unwanted items and retain any desirable items. Also, a continuous JVM does not invoke the ibmJvmTidyUp method to request the middleware classes to perform cleanup; this cleanup will only take place if the middleware classes perform it in the course of their normal actions. (The CICS-supplied middleware does perform cleanup without a request from the JVM.)

A continuous JVM can use the shared class cache (that is, it can be a worker JVM). JVMs that use the shared class cache start up more quickly, and have lower storage requirements, than JVMs that do not. The worker JVMs in a CICS region all have the same level of reusability as the master JVM in that region, so you cannot mix resettable worker JVMs and continuous worker JVMs in a CICS region; you need to choose one level of reusability for your worker JVMs. Setting up the shared class cache has more information about this.

Programming considerations for continuous JVMs explains the programming considerations for applications that run in a continuous JVM.