13.8.1 How to reload the J2EE applications

The methods of reloading J2EE applications include reloading by detecting updates and reloading by using commands.

Organization of this subsection
(1) Reloading by detecting updates
(2) Reloading by using commands

(1) Reloading by detecting updates

You can use the method of reloading by detecting updates as a functionality to support testing during the development of J2EE applications. The following figure shows the process of reloading by detecting updates:

Figure 13-7 Reloading by detecting updates

[Figure]

When the EJB applications (EJB-JAR) and Web applications (WAR) configuring the exploded archive-format J2EE application are updated, the J2EE sever detects the J2EE application updates and the updated EJB-JAR and WAR are reloaded automatically.

The J2EE server periodically monitors the J2EE application configuration file and reloads the J2EE application if a configuration file update is detected. The following figure shows the flow of processing from the update to the reload of J2EE applications:

Figure 13-8 Process flow of update detection-based reloading

[Figure]

The following is a description of points 1 to 10 in the figure:

  1. Update the J2EE application configuration file.
    Update the EJB-JAR and WAR files that configure the exploded archive-format J2EE application.
  2. J2EE server detects an update of the J2EE application configuration file.
    • The J2EE server periodically monitors the J2EE application configuration file and detects the update if the configuration file is updated. The interval between monitoring the J2EE application configuration file and detecting an update is set as the update detection interval. For details on the update detection interval, see 13.8.6 Update detection interval for J2EE applications.
    • After an update is detected, the J2EE server reloads the updated file. Sometimes the J2EE server might start loading the file while the file is being copied and the loading might fail. To avoid this, you can set the time from the detection of configuration file update to the start of monitoring of the requests being processed, as the interval for updating the configuration files. For details on the interval for configuration file update, see 13.8.7 Interval for updating the J2EE application configuration file.
    • When the JSPs are updated, the update is detected by JSP recompilation or by monitoring the class files. For details on the reloading of JSPs, see 13.8.9 Reloading the JSPs.
  3. The processing of the request is blocked.
    If the J2EE server detects a configuration file update and if the time specified in the interval for configuration file update lapses, the J2EE server locks the processing of the requests in order to reload the J2EE application.
    • For the EJB applications (EJB-JAR)
      An error is returned if a new request arrives. The processing continues if a request is being processed. However, by using the CTM for Stateless Session Bean, you can set a new request to a pending state.
    • For the Web applications (WAR)
      If a new request arrives, the request is added to the pending list. The processing continues if a request is being processed. If you use the delayed reloading functionality at this time, the reload start processing can be delayed. For details on delayed reloading, see 13.8.8(1) Delayed reloading of the Web applications.
      Reference note
      If the processing of the request being processed is not complete, you can start the reload processing by executing the method timeout and method cancellation functionality for monitoring the J2EE application execution time. For details on the relationship between reloading and the monitoring of the J2EE application execution time, see 13.8.10(2) Relationship between reloading and monitoring the J2EE application execution time.
  4. Execute the termination processing of the J2EE application.
    To execute the reloading process, terminate the J2EE application. The following processing is implemented during termination:
    • The servlet instance loaded into the class loader used before reloading is deleted. If the servlet implements the destroy method, the destroy method is executed. Even the servlet instances generated from the JSP files are destroyed. At this time, if the JSP file implements the jspDestroy method, the jspDestroy method is executed.
    • The objects registered in javax.servlet.ServletContext are destroyed.
    • The EJB instances loaded into the class loader used before reloading are destroyed. At this time, the following EJB callback methods are executed:
      CategoryExecuted method
      For Stateless Session BeanejbRemove
      PreDestroy
      For Stateful Session BeanejbRemove
      PreDestroy
      For an Entity BeanunsetEntityContext
      For a Message-driven BeanejbRemove
  5. Serialize the session information and output the information to the session information file.
    When a Web application is reloaded, you can continue to use the session information that was generated before reloading, even after reloading. For details on inheriting the session information, see 13.8.8(2) Inheriting the session information when the Web applications are reloaded.
  6. Create a class loader for J2EE applications.
    When a J2EE application is reloaded, the class loader for J2EE applications is created and is used to process the requests after reloading.
  7. Read the session information from session information file and de-serialize.
    When a Web application is reloaded, the session information output in the session information file is read in the new class loader.
  8. Delete the session information file.
  9. Start the J2EE application.
    • After reloading, an instance of the updated servlet is created during the first access, and the init method is executed.
    • With the start processing, the EJBs equal to the minimum value of the pool are generated and pooled. At this time, the following EJB callback methods are executed:
      CategoryExecuted method
      For Stateless Session BeansetSessionContext
      ejbCreate
      PostConstruct
      For an Entity BeansetEntityContext
      For a Message-driven BeansetMessageDrivenContext
      ejbCreate
  10. Cancel the blocking of requests and restart the processing of requests.
    The processing of requests that were pending in 3 is restarted.

(2) Reloading by using commands

You can use command-based reloading as a functionality to support testing during J2EE application development or as a functionality to support the replacement of J2EE applications when the system is running. The following figure shows command-based reloading.

Figure 13-9 Reloading by using commands

[Figure]

When the EJB applications (EJB-JAR) and Web applications (WAR) configuring an exploded archive-format J2EE application are updated, the user executes the cjreloadapp command. The J2EE server detects a J2EE application update through the cjreloadapp command and automatically reloads the updated EJB-JAR and WAR.

The following figure shows the flow of processing from the update to the reload of the J2EE application.

Figure 13-10 Process flow of command-based reloading

[Figure]

The following is a description of points 1 to 4 in the figure. Point 5 and later steps are the same as that for reloading by detecting updates. For point 5 and later steps, see (1) Reloading by detecting updates.

  1. Update the J2EE application configuration file.
    Update the EJB-JAR and WAR files that configure the exploded archive-format J2EE application.
  2. Execute the cjreloadapp command.
  3. The J2EE server detects an update of the J2EE application configuration file through the cjreloadapp command.
  4. The processing of the requests is blocked.
    The request processing is blocked in order to reload the J2EE application.
    • For the EJB applications (EJB-JAR)
      An error is returned if a new request arrives. The processing continues if a request is being processed. However, by using the CTM for Stateless Session Bean, you can set a new request to a pending state.
    • For the Web applications (WAR)
      If a new request arrives, the request is added to the pending list. The processing continues if a request is being processed.
      Reference note
      If the processing of the request being processed is not complete, you can start the reload processing by executing the method timeout and method cancellation functionality for monitoring the J2EE application execution time. For details on the relationship between reloading and the monitoring of the J2EE application execution time, see 13.8.10(2) Relationship between reloading and monitoring the J2EE application execution time.