Solution 2

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.

  1. Using CICSPlex SM:
    1. Clone your single listener/AOR.
    2. 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:
      1. 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.
      2. 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.
  2. On the original region:
    1. Check when all instances of bean1 through bean6 have been destroyed or passivated:
      1. 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.
      2. Use the INQUIRE TASK command to check whether any instances of these transactions are running.
    2. 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:
      1. Put the new version of the DJAR3.jar deployed JAR file into CorbaServer COR2's pickup directory.
      2. 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:
      1. Issue a CEMT DISCARD DJAR(DJAR3) command to delete the old definition of DJAR3.jar.
      2. 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:
      1. 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.
      2. 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.
      3. 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.
  3. 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:
    1. 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.
    2. 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.
  4. 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.