Hitachi

uCosminexus Application Server Operation, Monitoring, and Linkage Guide


5.5.2 Lock process

In the lock process, from among the elements configuring the J2EE applications to be locked, lock the front part that receives requests, thus stopping the receipt of new requests.

Note that the request being processed is processed uninterruptedly.

Organization of this subsection

(1) Lock sequence and process contents

Lock procedure:

  1. Lock process of the Web application

  2. Lock process of the CTM schedule queue#

  3. Lock process of the front-end EJB

    #

    If the system is not integrated with CTM, the lock process of the CTM schedule queue does not exists.

The following sections explain the processing in each lock process:

(a) Lock process of the Web application

The following processes are executed:

  • Terminate the receipt of new requests.

  • Continue processing the requests that are being processed.

  • Among the requests exist in the queue that controls the number of concurrently executed requests of the Web application, the requests for which processing has not started in the Web container are not processed. All the processes return the 503 error to the client.

(b) Lock process of the CTM schedule queue

The following processes are executed:

  • Terminate the receipt of new requests.

  • Among the requests entered in the CTM schedule queue, only the requests distributed to the J2EE server are processed. The exception java.rmi.RemoteException is thrown to the client.

  • Among the requests entered in the CTM schedule queue, the processing of the requests continues, for which processing has already been started in the J2EE server.

(c) Lock process of the front-end EJB

The following processes are executed:

  • Terminate the receipt of new requests.

  • Continue processing the requests that are being processed.

(2) Configuration pattern and locking methods of J2EE applications

The following figure shows the form of J2EE application for the locking method of each configuration pattern of the J2EE application and describes each locking method:

Figure 5‒13: Configuration pattern of a J2EE application

[Figure]

For details on specifying the front-end EJB, see 5.5.6 Settings for execution environment.

(3) Precautions when executing the lock process

It is necessary to take care of the following points when executing the lock process:

(a) Precautions when using CTM

You must take the following precautions for executing the lock process, when CTM is used:

  • When the Web application or EJB use CTM to access the EJB present in the same J2EE application

    When the lock process finishes, even the requests that are being processed throw an exception to the client. In such cases, terminate the processing of the client that invokes the applicable Web application or EJB, and then stop the J2EE application.

  • When a request is entered without using CTM for EJB invoked from CTM after the lock process

    New request is received since the EJB lock process is not implemented. In such cases, stop the processing of the client that invokes the applicable EJB, and then stop the J2EE application.

  • When 0 is specified in the ejbserver.ctm.DeactivateTimeOut key of usrconf.properties

    In usrconf.properties, do not specify 0 in the ejbserver.ctm.DeactivateTimeOut key.

    If 0 is specified and an attempt is made to stop the application when a request is being processed via CTM, the lock process does not end until the request is complete. Therefore, if the request is incomplete due to failure, you cannot execute the forced termination.

(b) Precautions when invoking Web applications across J2EE applications

In a Web application, you can use getContext of javax.servlet.ServletContext and access a Web application on the same Web container. When the Web application to be accessed is deployed on another J2EE application, first stop the J2EE application that includes the calling front-end Web application.