Resettable JVM
The resettable JVM was introduced in CICS TS Version 2.1. With it you could reset the state of a JVM between tasks to help ensure that subsequent users of the same JVM are fully isolated from states left behind by previous users of the JVM.
The time taken to reset a JVM depended on no cross-heap references between the middleware and application heaps. If references exist, the JVM scan to determine if the references are in live objects can be slow. If the attempt to reset the JVM failed, CICS discarded the JVM and created a new one. These unresettable events (UREs) were a major performance problem for some users of CICS TS and Java.
Support for the resettable JVM was removed in CICS TS 3.2. Anyone using a resettable JVM in earlier versions of CICS are encouraged to migrate to a continuous mode JVM.
The information in this appendix is for historical reference only.
Resettable JVM
The resettable JVM can be started and used to run consecutive Java applications, resetting its storage areas between each program invocation. This mode of operation offers the same isolation as the single use mode, which means that it prevents changes to the state of the JVM made by an application program affecting the operation of the next program run in that same JVM. However, it is much more efficient than single use mode, for these reasons:
•It avoids the overhead of destroying and starting the JVM.
•Classes and JIT-compiled code can be shared between JVMs, thus reducing I/O (for loading classes) and CPU time (for JIT compilation).
The JVM divides classes into categories of well-behavedness or trustworthiness, and it also monitors the behavior of application classes. If an application class changes the JVM state in a way that could potentially affect the next program run on that JVM, the JVM is marked unresettable and is destroyed after the program terminates.
The storage heap is divided up into a number of areas, each with its own class loader. These areas are treated differently during reset processing.
There is a transient heap, which contains objects that a Java application creates as it executes. All of these objects are deleted at reset time. There is also a separate trusted middleware heap that is used for middleware classes that are trusted to reset the object they create to some known state, as part of reset processing.
Resetting the JVM involves a check to see if any pointers exist from the middleware heap to the application heap. If there are none, the application heap is thrown away, which is a very cheap garbage collection operation.
If pointers do exist, a search similar to full garbage collection occurs to determine whether the pointers are live or not.
Resets can also fail for a number of application-related reasons, such as the changing of a system property or the loading of a native library. If the reset operation fails to complete, CICS is informed of this and terminates the JVM. See “Unresettable actions” on page 298 for details.
In summary, the resettable JVM provides the benefits of reuse while offering the greatest protection between program invocations.
Unresettable actions
A resettable JVM must be discarded after an application program changes its state in a way that might affect another program that is running on that JVM. Therefore, to benefit from using the JVM in resettable mode, you must ensure that your applications stick to certain rules.
If an application program performs one of these actions, the JVM becomes unresettable:
•Writing to a static variable that is associated with a class that is loaded by either the bootstrap class loader or the extensions class loader
•Setting system properties:
– java.lang.System.setProperty()
– java.lang.System.setProperties()
– java.lang.System.getProperties()
The first two are special cases of the modification of a static variable (in effect, they are write accesses to the static variable System.props).
•Closing or redirecting the standard input, output, or error streams:
– System.err.close(), System.in.close(), System.out.close()
– java.lang.System.setErr(), java.lang.System.setIn(), java.lang.System.setOut()
Again, these are special cases of writing to a global static variable.
•Loading a native library:
– java.lang.System.loadLibrary()
– java.lang.System.load()
– java.lang.Runtime.loadLibrary()
– java.lang.Runtime.load()
Because the JVM cannot know if native library code changes its state in one of the other ways described here, it marks itself as being unresettable.
•Using the Abstract Windowing Toolkit (AWT) or any of its derivatives to access a display or keyboard, or to print.
•Several security-related actions, such as setting the security manager or attempting to access or modify the security configuration objects (Policy, Security, Provider, Signer, Identity).
•Using any of the thread methods to start, stop, resume, suspend, or interrupt threads.
•Creating a new process using Runtime.exec().
•Loading a non-checked standard extension.
Checked standard extensions are those extensions that were checked for writable statics. The writable statics are either not exposed to application code or checks were added to the standard extension to detect any changes that are made.
Checked extensions are identified by the presence of a manifest entry in the main section of their JAR files:
IBM-Reusable-JVM-Compatible: True
•Using the JVM in debug mode (Xdebug option).
Checking for reset behavior
CICS provides logging facilities to assist you in obtaining whether and why an application program caused a JVM to become unresettable.
|
Tip: This facility is not only useful for making your applications resettable-friendly, it is also a good start for migrating your applications from the resettable JVM to the continuous JVM. Many of the events that render a JVM unresettable can be potential problems when running in continuous mode.
|
Logging the events that cause a JVM to be marked as unresettable is controlled through the system properties file:
ibm.jvm.events.output=log file name
ibm.jvm.unresettable.events.level=max (Use this setting for development/test.)
or
ibm.jvm.unresettable.events.level=min (Use this setting for production.)
The three events to look out for are:
•UnresettableEvent
This is the worst type because it means that the JVM is marked unresettable and must be terminated. A textual description of the event tells you why that happened, and you will see a stack trace that tells you where in the application code it happened.
•ResetTraceEvent
This event means that there are cross-heap references from middleware objects to application objects, which is still bad, but not as bad as an UnresettableEvent because it does not necessarily mean that the JVM must be terminated.
For an in-depth discussion about ResetTraceEvents and how to get rid of them, refer to Persistent Reusable Java Virtual Machine User’s Guide, SC34-6201.
•ResetJVMEvent
This is the good one because it means that the JVM reset cleanly.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.