The resettable JVM is kept in the JVM pool for reuse. The JVM is initialized once, and is reused many times. It can be reset to a known state between uses. A resettable JVM has the option REUSE=RESET in its JVM profile (or the older option Xresettable=YES).
The resettable JVM is normally reset between transactions; that is, after the application code has terminated for one transaction and before the application code starts for the next transaction. If more than one Java™ program is used in a transaction, the resettable JVM is reset after each Java program has completed. This level of reusability is equivalent to specifying the -Xresettable option for a JVM.
The JVM reset isolates invocations of Java programs from changes made by previous invocations of programs in the same JVM. This means that programs cannot create persistent items that might be of use to future executions of the same program, but it also means that programs cannot leave unwanted state in the JVM, or change the state of the JVM. However, the time and CPU usage required for a JVM reset reduce the performance of a resettable JVM compared to the performance of a continuous JVM. An application that has been coded with attention to the state of the JVM and to the items in static storage can operate safely without the JVM reset, so it can run in a continuous JVM to achieve performance enhancements.
If one or more unresettable events are detected during the execution of a user's Java program, the JVM is marked unresettable, and CICS destroys the JVM when the Java program has finished using it. The storage used by the JVM is recovered, and a new JVM is initialized. The events that prevent reuse are logged, provided that the appropriate event logging system properties are specified in the JVM properties file for the JVM.
Middleware classes, that is, classes specified on the trusted middleware class path for the JVM, are permitted to perform unresettable actions without the JVM being marked unresettable. This is because they are trusted by the JVM to perform the actions necessary to reset themselves between transactions. You should use the application class paths for your own application classes, to ensure that if they do perform an unresettable action in a resettable JVM, the JVM is destroyed. Classes in a JVM explains more about the different classes and class paths in a JVM.
A resettable 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.
Programming considerations for resettable JVMs explains the programming considerations for applications that run in a resettable JVM.