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:
- 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.
- 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:
- During the upgrade process, different AORs would have different versions
of the beans. Unless the new versions of the beans were completely backward-compatible
with the old versions, this would cause unpredictable effects. (“Completely
backward-compatible” means that, among other things, the home and component interfaces of the two versions must be identical, and the state
of any stateful session beans must be preserved.)
- Shutting down even one AOR would inevitably degrade the performance of
the EJB server to some extent. (If the upgrade is an important one, this might
be acceptable. To compensate for the degraded performance you could, perhaps,
add an extra AOR to your EJB server.)
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.
For some suggested solutions to our problem of how best to
update beans in a production region, see Possible solutions.