Solution 2

This solution requires CICSPlex® System Manager. It is a development of solution 2 for a single-region. Its advantage is that 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. Its disadvantage is that it is more complicated to implement than solution 1.

  1. Using CICSPlex SM:
    1. Create clones of all your AORs.
    2. Direct all new workload to the clones—that is, quiesce the original AORs and activate the clones. For information on how to do this, see the CICSPlex System Manager Managing Workloads manual.

      Each request for a bean method that will run under a new OTS transaction, or under no OTS transaction, whether in COR1 or COR2, is routed to one or other of the clones.

      Each request for a bean method that will run under an existing OTS transaction (whether in COR1 or COR2) is routed to the appropriate original AOR.
      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 clones.
      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 clones.
      3. By “the appropriate original AOR” we mean the original AOR containing the request processor for the OTS transaction.
  2. On each of the original AORs:
    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.
  3. When all instances of bean1 through bean6, on all the original 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:
    1. Put the new version of the DJAR3.jar deployed JAR file into COR2's pickup directory (which is shared by all the original AORs).
    2. On each of the original AORs, issue a PERFORM CORBASERVER(COR2) SCAN command. The AOR 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. On each of the original AORs, issue a CEMT DISCARD DJAR(DJAR3) command to delete the old definition of DJAR3.jar.
    2. On each of the original AORs, 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.
  4. Using CICSPlex SM, direct all new workload to the original AORs—that is, quiesce the clones and activate the original AORs.
    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 AORs. 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 clones.
    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 AORs.
    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 AORs.
    Eventually, all instances of enterprise beans on the clones will be destroyed or passivated.
  5. On each of the clones, 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.