Programming considerations for continuous JVMs

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.

Protecting the state of a continuous 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.

Static state 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.

However, you must take care when designing and coding your applications that you do not leave any unwanted state in a continuous JVM. Because the static storage is not reinitialized for each invocation of the program in a continuous JVM, your program must reinitialize its own static storage, if it depends on the state of a changeable class field. Static variables in a continuous JVM can exist through a number of CICS® tasks, and their value might not be predictable. This is true for static variables in all classes, both application and system classes, and includes classes which might affect the application, but are not used explicitly (including those used in static initializers). Try to identify and eliminate any changeable class fields and static initializers that have not been included deliberately as part of the application's design. Consider the following guidelines:
  • Define a class field as private and final whenever possible. Be aware that a native method can write to a final class field, and a non-private method can obtain the object referenced by the class field and can change the state of the object or array.
  • Be aware of system-loaded classes that use changeable class fields.

Further programming tips for a continuous JVM:

Applying a Java 2 security policy
If you want to monitor and police any potentially unsafe actions in a continuous JVM, consider enabling the Java 2 security policy mechanism. By default, CICS does not enforce a Java 2 security policy. When you enable the security manager for a JVM, you can specify security policy files to give applications permission only for actions which you consider safe. CICS provides a Java 2 security policy file, dfjejbpl.policy, which can be used to restrict the permitted operations for a Java application in CICS to only those operations permitted for enterprise beans. You may choose to use this policy file, and to provide further policies of your own, if wanted. Protecting Java applications in CICS by using the Java 2 security policy mechanism has more information about applying a security policy.
Accessing DB2
After a Java application running in a continuous JVM has accessed DB2, it is important that it closes the DB2 connection. This is because subsequent executions of the same application in the continuous JVM will try to open a new DB2 connection. This fails if a previous connection has not been closed.
Middleware
If you are writing middleware to run in a continuous JVM, note that a continuous JVM does not invoke the ibmJvmTidyUp method to request the middleware classes to perform cleanup. The middleware classes must perform any cleanup that is required without being prompted by this request. (The CICS-supplied middleware does perform cleanup without a request from the JVM.) Persistent Reusable Java Virtual Machine User's Guide, SC34-6201, explains how middleware should be written.