The shared class cache contains:
- The IBM®-supplied middleware that you need to run enterprise beans and Java
applications, and any other middleware classes that you have specified (on
the trusted middleware class path).
- Any application classes that are loaded by shared application class loaders,
including classes on the shareable application class path, and classes that
are loaded from a DJAR.
The structure of a JVM has more details about these classes.
If any of these classes or JAR files change, you need to update them in
the shared class cache, because they are not automatically reloaded. This
does not apply to classes loaded by the nonshareable
class loader, that is, classes on the standard class path specified by the
CLASSPATH option in the JVM profile, because they are loaded into the individual
worker JVMs.
If you need to update any of the classes or JAR files in the shared class
cache, first update the classes or files on your system. Next, phase out the
old shared class cache and create a new shared class cache. The new shared
class cache will contain the new classes or JAR files that you have placed
on your system.
You can phase out the old shared class cache using one of three commands,
depending on how you want the new shared class cache to be introduced. Once
you have entered one of these commands, either CICS will create a new shared
class automatically, or you will need to create a new shared class cache manually.
The three commands that you can use are listed here, with a description of
what happens when you use each command, and what you need to do next. Read
the list to identify the command that is most appropriate for your situation. Table 1, following the list, summarizes when you should use each
command.
The commands you can use to update classes or JAR files in the shared class
cache are:
- CEMT PERFORM CLASSCACHE RELOAD
(or the equivalent EXEC CICS command).
This command creates a new
shared class cache using the new classes or JARs. You can only use this command
when the status of the shared class cache is STARTED. When you reload the
shared class cache, worker JVMs, both those that are already allocated to
tasks and those that are allocated to tasks after you issue the command, continue
to use the existing shared class cache until the new shared class cache is
ready. When the new shared class cache is ready, subsequent requests for
worker JVMs are given a worker JVM that uses the new cache. These new worker
JVMs are started as they are requested by applications, and they replace the
worker JVMs that are using the old shared class cache. The worker JVMs that
are using the old shared class cache are allowed to finish running their current
Java programs, and then they are terminated. The old shared class cache is
deleted when all the worker JVMs that are dependent on it have been terminated.
CEMT PERFORM CLASSCACHE RELOAD is the least disruptive of the commands
listed here, but it does mean that the old versions of the class or JAR files
continue to be used until the process is complete. CEMT PERFORM CLASSCACHE
RELOAD has no effect on standalone JVMs that are not sharing the class cache.
When you have entered CEMT PERFORM CLASSCACHE RELOAD, you do not need
to take any further action, because CICS automatically creates the new shared
class cache as a result of the command.
- CEMT PERFORM CLASSCACHE PHASEOUT,
PURGE or FORCEPURGE (or the equivalent EXEC CICS command).
This command
terminates all the worker JVMs that are dependent on the shared class cache,
and then deletes the shared class cache itself. You can choose to purge or
forcepurge the worker JVMs, or allow them to finish running their current
Java programs before they are deleted. New JVMs that start up after you issue
the command cannot use the shared class cache that is
being terminated. This command has no effect on standalone JVMs that are not
sharing the class cache.
When you have entered CEMT PERFORM CLASSCACHE
PHASEOUT, PURGE or FORCEPURGE:
- If autostart is enabled, as soon as a new JVM requests the use of the
shared class cache, a new shared class cache is started, and this new shared
class cache contains the new versions of the classes or JAR files. There will
be a slight delay while the new shared class cache is initialized, during
which requests will wait. All subsequent JVMs that require the shared class
cache will use the new shared class cache.
- If autostart is disabled, you need to take action to ensure that a new
shared class cache is started. You can use the AUTOSTARTST option on the CEMT
PERFORM CLASSCACHE PHASEOUT, PURGE or FORCEPURGE command (or the equivalent
EXEC CICS command) to enable autostart, in which case a new shared class cache
is created as soon as a new JVM requests the use of the shared class cache.
Alternatively, if you want to keep autostart disabled, you need to start a
new shared class cache using the CEMT PERFORM CLASSCACHE START command (or
the equivalent EXEC CICS command). You can enter this command while the old
shared class cache is being terminated; you do not need to wait for termination
to complete. Enter the command as soon as you can, because while the status
of the shared class cache is STOPPED, requests to run a Java application in
a JVM whose profile requires the use of the shared class cache (that is, requests
for worker JVMs) will fail. After you enter the command, making the status
of the shared class cache STARTING, the requests will wait. The new shared
class cache that you start (whether manually or by enabling autostart) contains
the new versions of the classes or JAR files.
After the new shared class cache starts, the old shared class cache remains
in the system until all the worker JVMs that are dependent on it have been
terminated, and then it is deleted. You can use the
CEMT INQUIRE CLASSCACHE command (or the equivalent EXEC CICS command)
to report on any old shared class caches in your system, and the number of
JVMs that are dependent on them.
- CEMT SET JVMPOOL PHASEOUT,
PURGE or FORCEPURGE (or the equivalent EXEC CICS command).
This command
terminates all the JVMs in the JVM pool, both those sharing the class cache
and those running independently as standalone JVMs, and it terminates the
shared class cache. You can choose to purge or forcepurge the JVMs, or allow
them to finish running their current Java programs before they are deleted.
When you have entered CEMT SET JVMPOOL PHASEOUT, PURGE or FORCEPURGE
(or the equivalent EXEC CICS command):
- For standalone JVMs that do not use the shared class cache, CICS will
start these automatically as they are needed. New standalone JVMs that start
up after you have issued the command will use the new versions of the classes
or JAR files. They can start up right away, and do not need to wait until
all the JVMs in the pool have been terminated.
- For worker JVMs that use the shared class cache:
- If autostart is enabled, the result is the same as with the CEMT PERFORM
CLASSCACHE PHASEOUT, PURGE or FORCEPURGE command. A new shared class cache
is started as soon as a new JVM requests it.
- If autostart is disabled, you need to start a new shared class cache using
the CEMT PERFORM CLASSCACHE START command (or the equivalent EXEC CICS command).
You can enter this command while the old shared class cache is being terminated;
you do not need to wait for termination to complete. When autostart is disabled,
and the status of the shared class cache is STOPPED (that is, after you have
entered the CEMT SET JVMPOOL PHASEOUT, PURGE or FORCEPURGE command), requests
to run a Java application in a JVM whose profile requires the use of the shared
class cache (that is, requests for worker JVMs) will fail. After you enter
the CEMT PERFORM CLASSCACHE START command, making the status of the shared
class cache STARTING, the requests will wait rather than fail. To avoid the
possible failure of requests for JVMs, if you are planning to restart the
shared class cache, it is advisable to use the CEMT
SET CLASSCACHE AUTOSTARTST command (or the equivalent EXEC CICS command)
to enable autostart before using the CEMT SET JVMPOOL PHASEOUT, PURGE or FORCEPURGE
command. This ensures that a new shared class cache is started as soon as
it is needed.
As with the CEMT PERFORM CLASSCACHE PHASEOUT, PURGE or FORCEPURGE command,
the old shared class cache remains in the system until all the worker JVMs
that are dependent on it have been terminated, and then it is deleted.
Table 1 summarizes when you should use each command to update
classes or JAR files in the shared class cache.
Table 1. Updating
classes or JARs in the shared class cacheSituation |
Suitable command |
- You want to allow new JVMs requiring the shared class cache to use the
old classes or JARs until the new shared class cache is ready.
- You have no standalone JVMs, or you do not want to update this type of
JVM.
|
CEMT PERFORM CLASSCACHE RELOAD (or the equivalent EXEC
CICS command) |
- You want to ensure that all new JVMs requiring the shared class cache
from now on must wait until the new shared class cache is ready, and not use
the old classes or JARs.
- You have no standalone JVMs, or you do not want to update this type of
JVM.
|
CEMT PERFORM CLASSCACHE PHASEOUT, PURGE or FORCEPURGE
(or the equivalent EXEC CICS command), using the AUTOSTARTST option to enable
autostart if it is not already enabled |
- You want to update the classes or JARs in standalone JVMs, as well as
in the shared class cache.
|
CEMT SET JVMPOOL PHASEOUT, PURGE or FORCEPURGE (or the
equivalent EXEC CICS command), followed as soon as possible by CEMT PERFORM
CLASSCACHE START (unless autostart is enabled, in which case you do not need
to use CEMT PERFORM CLASSCACHE START) |
You can use the CEMT INQUIRE CLASSCACHE command
(or the equivalent EXEC CICS command) to report on any old shared class caches
in your system (OLDCACHES), and the number of JVMs that are dependent on them
(PHASINGOUT). If you want to check the status of the JVMs themselves, including
standalone JVMs, you can use the CEMT INQUIRE JVM command
(or the equivalent EXEC CICS command) to report on all the JVMs in the JVM
pool, including those that are being phased out. (The INQUIRE JVM command
does not find the master JVM that initializes the shared class cache. It only
finds worker JVMs and standalone JVMs.)