When you are developing Java™ applications to run in a continuous JVM, you can create persistent items that might be of use to future executions of the same application in the same JVM, but you also need to ensure that programs do not change the state of the JVM in undesirable ways, or leave any unwanted state in the JVM.
The continuous JVM does not isolate invocations of Java programs from changes made to the JVM by previous invocations of programs in the same JVM. User application classes, as well as middleware classes, that run in a continuous JVM are able to change the state of the JVM in ways that might affect subsequent program invocations. For example, a program might reset the default time-zone (if not prohibited by a security manager), and do calculations based on this time-zone. Subsequent invocations of the program would use the new default time-zone, which might not be appropriate. In a resettable JVM, such actions would be considered unresettable actions, and cause the JVM to be destroyed.
Unresettable actions are not recorded in a continuous JVM. To help eliminate unresettable actions where they are not desired, during the development process, you can test the program in a resettable JVM (with the option REUSE=RESET). Resettable JVMs record unresettable actions, and you can use this information to help you re-design the application if necessary. Programming considerations for resettable JVMs tells you how to make a JVM record unresettable actions. When you know that the program does not change the state of the JVM in undesirable ways, you can move to using it in a continuous JVM.
Invocations of Java programs in a continuous JVM are able to pass on state to subsequent invocations of programs in the same JVM. You can use this to your advantage in designing your Java applications if you want information to persist from one program invocation to the next. Because static state and object instances referenced through static state are not reset between JVM reuses in a continuous JVM, it is permissible for applications to create persistent items that might be of use to future executions of the same application in the same JVM.
Imagine an operation that reads DB2® information in order to construct a complex data structure; this might be an expensive operation that should not be repeated more times than absolutely necessary. With a continuous JVM, the complex data structure can be stored in application static and be accessible to later executions of the application in the same JVM, thus avoiding unnecessary initialization. (If objects are anchored in static, that is, in the static class fields, then they are never candidates for garbage collection.) This is also possible with a resettable JVM, but would require the development of middleware code, which is a step up in complexity from developing application code.
If you design an application in this way, remember that there is no guarantee that subsequent executions of an application (or even executions of a different Java program within the same transaction), will be assigned a JVM containing the items that were created by the first execution of the application. The subsequent executions of the application might be assigned a newly created JVM, or a JVM that has been re-initialized following a mismatch or a steal, or a JVM that has been used by a different application which cleared the JVM's storage heaps. Your application should not rely on the presence of the persistent items that you create in the JVM; it should check for their presence in order to avoid unnecessary initialization, but it should be prepared to initialize them if they are not found in the present JVM.