This solution is a development of solution 1 for a single-region. Its advantage
is that it is relatively easy to implement. Its disadvantage is that it is
not seamless—that is, there is a period (while instances of the old
versions of bean5 and bean6 are being destroyed or passivated)
during which it is impossible to create a new instance of bean5 or bean6.
- On each of the AORs, issue an EXEC CICS SET CORBASERVER(COR2)
ENABLESTATUS(DISABLED) or a CEMT SET CORBASERVER(COR2)
DISABLED command. On all the AORs:
- Any attempts to create new instances of bean5 or bean6, regardless of whether the clients have references to the beans'
home interfaces, will fail.
- Typically, currently-executing methods on instances of bean5 and bean6 will proceed to completion.
- An instance of bean5 or bean6 that is not participating
in an OTS transaction is destroyed or passivated at the end of the currently-executing
method. (If there is no currently-executing method, all instances will already
have been destroyed or passivated.)
- An instance of bean5 or bean6 that is participating in an OTS transaction is not destroyed or passivated
until the end of the OTS transaction; typically, any future method calls against
this instance (within the scope of the OTS transaction) will succeed. At the
end of the OTS transaction the instance is destroyed or passivated.
- On each of the AORs, check when all instances of bean5 and bean6 have been destroyed or passivated by issuing EXEC CICS or CEMT
INQUIRE CORBASERVER(COR2) ENABLESTATUS commands. A status of DISABLED
indicates that all bean instances have been destroyed or passivated.
- When all instances of bean5 and bean6, on all the
AORs, have been destroyed or passivated, install the updated version of the DJAR3.jar deployed JAR file, using either the CICS scanning mechanism
or static DJAR definitions. (You cannot use the scanning mechanism to update
static DJAR definitions.)
Either:
- Put the new version of the DJAR3.jar deployed JAR file into
CorbaServer COR2's pickup directory (which is shared by all
the AORs).
- On each of the AORs, issue a PERFORM CORBASERVER(COR2) SCAN
command. The AOR scans COR2's pickup directory, installs the
new definition of DJAR3.jar, and copies the new versions of bean5 and bean6 to COR2's shelf directory.
or, on each of the AORs:
- Issue an EXEC CICS or CEMT DISCARD DJAR(DJAR3) command, to
remove the current definition of DJAR3.jar from CICS.
- Issue a CEDA INSTALL DJAR(DJAR3) or an EXEC CICS CREATE DJAR(DJAR3) CORBASERVER(COR2) HFSFILE(new_version_of_DJAR3.jar_on_HFS) command. CICS installs the new definition of DJAR3.jar,
and copies the new versions of bean5 and bean6 to COR2's shelf directory.
Note: - It is not necessary to re-publish the updated
versions of bean5 and bean6 to the namespace, even if
the home or component interfaces of the beans have changed since the previous
version.
- If the home or component interface of bean5 or bean6 has
changed since the previous version, before using the changed bean client applications
must be updated to use the new signature.
- If you update a stateful session bean, depending
on exactly what changes are made you may change the structure of its serialised
state. If this happens, you will invalidate any passivated instances of the
bean in the object store. If this happens, any attempts to use the now invalidated
bean will result in an exception. You should code your client applications
to cope with this possibility.
- On each of the AORs, issue a CEMT SET CORBASERVER(COR2) ENABLED
command. From this moment, all new work will use the updated
versions of bean5 and bean6.