This solution requires CICSPlex® System Manager. All CICS applications on your listener/AOR
must be suitable for cloning across multiple regions.
The advantage of this solution is that, unlike solution 1, it is relatively
seamless—that is, there should at worst be only a tiny period during
which it is impossible to create a new instance of bean5 or bean6. The disadvantage is that it is more complicated to implement
than solution 1.
- Using CICSPlex SM:
- Clone your single listener/AOR.
- Direct all new workload to the clone—that is, quiesce the original
AOR and activate the clone. For information on how to do this, see the CICSPlex System Manager Managing Workloads manual.
All requests for bean methods that will run under
a new OTS transaction, or under no OTS transaction, whether in COR1 or COR2,
are routed to the clone.
Requests for bean methods that will run under
an existing OTS transaction (whether in COR1 or COR2) are routed to the original
region.
Note: - By “a new OTS transaction” we mean an
OTS transaction in which the bean's participation begins after all new work is directed to the clone.
- By “an existing OTS transaction” we mean
an OTS transaction in which the bean's participation began before all new work was directed to the clone.
On the original region:
- An instance of an enterprise bean 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 an enterprise bean 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 the original region:
- Check when all instances of bean1 through bean6 have
been destroyed or passivated:
- If you don't already know the CICS transaction ID or IDs associated
with bean1 through bean6, use the CREC transaction to
display this information.
- Use the INQUIRE TASK command to check whether any instances of these transactions
are running.
- When all instances of bean1 through bean6 have been
destroyed or passivated, install the updated version of the DJAR3.jar deployed JAR file, using either the CICS scanning mechanism or a static
DJAR definition. (You cannot use the scanning mechanism to update a static
DJAR definition.)
Either:
- Put the new version of the DJAR3.jar deployed JAR file into
CorbaServer COR2's pickup directory.
- Issue a PERFORM CORBASERVER(COR2) SCAN command. CICS scans COR2's pickup directory, updates its definition of DJAR3.jar, and copies the new versions of bean5 and bean6 to COR2's shelf directory.
or:
- Issue a CEMT DISCARD DJAR(DJAR3) command to delete the old
definition of DJAR3.jar.
- 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.
- Using CICSPlex SM, direct all new workload to the original region—that
is, quiesce the clone and activate the original region.
All requests for
bean methods that will run under a new OTS transaction, or under no OTS transaction,
whether in COR1 or COR2, are now routed to the original region.
From this moment, all new work will use the updated versions of bean5 and bean6. Requests for bean methods that will run
under an existing OTS transaction (whether in COR1 or COR2) continue to be
routed to the clone.
Note: - By “a new OTS transaction” we mean an
OTS transaction in which the bean's participation begins after all new work is redirected to the original region.
- By “an existing OTS transaction” we mean
an OTS transaction in which the bean's participation began before all new work was redirected to the original region.
Eventually, all instances of enterprise beans on the clone will
be destroyed or passivated, as described above.
- On the clone region, use the INQUIRE TASK command to check when all instances
of bean1 through bean6 have been destroyed or passivated.
When this has happened, you can discard the clone region.