The problem

How do you update enterprise beans in a running CICS® production region, while causing the minimum disruption to the current workflow and without recycling CICS?

It is simple enough to introduce new enterprise beans into a running EJB server without disrupting the current workflow. You can do either of the following:
  1. Use the CICS scanning mechanism. That is, place the deployed JAR file containing the new beans into a CorbaServer's deployed JAR file (“pickup”) directory and issue a PERFORM CORBASERVER SCAN command. Repeat on all the AORs in the logical EJB server. If the CORBASERVER definition specifies AUTOPUBLISH(NO), on one of the AORs issue a PERFORM DJAR PUBLISH command.
    Note: If you use the scanning mechanism in a production region, be aware of the security implications: specifically, the possibility of CICS command security on DJAR definitions being circumvented. To guard against this, we recommend that user IDs given write access to the HFS deployed JAR file directory should be restricted to those given RACF® authority to create and update DJAR and CORBASERVER definitions.
  2. Use an EXEC CICS CREATE DJAR command to install a definition of the deployed JAR file which contains the new beans. Repeat on all the AORs in the logical EJB server. On one of the AORs, issue a PERFORM DJAR PUBLISH command.

Unfortunately, because of the unpredictable effects on in-flight transactions, you can't use these methods to update beans in an active EJB server. You would have no way of controlling which version of a bean, the old or the new, was used by successive method calls. (Because of timing differences, the problem could well be exacerbated in a multi-region EJB server.)

An alternative approach would be to quiesce and shut down CICS, then restart it with the updated DJAR definitions in place. While this is acceptable in a test environment, it is not an attractive solution for a production region. Consider Figure 1. Imagine that you want to update bean5 and bean6 in CorbaServer COR2. If you were to close down CICS, not only would bean5 and bean6 be unavailable during the shutdown, but also all the beans in CorbaServer COR1.

What if your EJB server contains several AORs, with workload management being used to balance requests across them? Could you not then shut down and upgrade each AOR in turn, with a minimal effect on performance? Unfortunately not, because:

The rest of this section discusses what you need to do on a CICS EJB server to update enterprise beans in production regions. Note that changes may also be required on the client side. In particular, if, due to an update, the home or component interface of an enterprise bean changes, before any client applications can use the updated bean they must be rewritten to use the new interface.

Figure 1. A CICS EJB production region. The clients are invoking bean methods in CorbaServers COR1 and COR2.

You are recomended to divide beans between CorbaServers based on the beans' maintenance and availability requirements.

The picture shows a CICS EJB production region. The region is a combined listener/AOR. It contains two CorbaServers, COR1 and COR2. COR1 contains four enterprise beans, bean1, bean2, bean3, and bean4, which it has installed from its HFS pickup directory. COR2 contains two enterprise beans, bean5 and bean6, which it has installed from a different HFS pickup directory. Two client workstations are invoking methods of beans in both COR1 and COR2.

For some suggested solutions to our problem of how best to update beans in a production region, see Possible solutions.