5.3.4 Method Cancellation
The method cancellation functionality cancels the running process that is the cause of timeout. When canceling the method, determine whether the process being currently executed can be cancelled.
- Tip
-
When using a resource adapter compliant with the Connector 1.5 specifications, the following processes cannot be specified for method cancellation:
-
Resource adapter specific methods
-
Work executed in work management
However, the processes in the Message-driven Bean invoked by Work can be specified for method cancellation.
-
- Organization of this subsection
(1) Protected area and non-protected area
The area where a method can be cancelled is known as a non-protected area and the area where a method cannot be cancelled is known as a protected area.
Protected area is the area where a method cannot be cancelled. The protected area maintains data and area shared by J2EE server operations and guarantees the process executed in JavaVM, and hence, that method cannot be cancelled. The J2EE service, Web container, and EJB container are the protected areas. For details on the contents defined as protected area, see Appendix C. Contents of the Protected Area List. In addition to the classes relevant to the protected area described here, if there are classes you want to handle as protected area, you describe the classes in the Protected area list file.
On the other hand, the non-protected area is where the methods can be cancelled. A J2EE application is a non-protected area.
The judgment of protected area and non-protected area is performed for each class. However, there are times when non-protected area is handled as a protected area depending upon the runtime conditions. Even a J2EE application is determined as a protected area, when a native method is invoked or when a static initializer is executed. Furthermore, from the wait method of the java.lang.Object class is determined as an exceptional non-protected area, only in the cases where the method is not invoked in the extension of the static initializer.#
# In versions subsequent to the wait method of the java.lang.Object class acquires the thread monitor (lock), when the process is restarted due to the lapse of the specified time or notify/notifyAll. If the protected area is determined while waiting for acquiring the monitor, the area is determined as a non-protected area, but cancellation is actually executed immediately after the thread monitor is acquired.
(2) Method cancellation processing
A method can be cancelled only when the process currently executed is in the non-protected area. To confirm whether a method can be cancelled, when determining the protected area, determine whether the method that is to be cancelled is being executed in the non-protected area. Method is cancelled when the process being executed is in the non-protected area. In case of a protected area, the process of determining the protected area is retried at fixed intervals. Whenever the area is determined as a protected area in the determining process, the KDJE52718-W message is displayed. When the control does not move to non-protected area in a fixed time, it is considered that method cancellation has failed and the method cancellation process terminates.
The following figure shows the flow of the process for determining the protected area:
|
|
![[Figure]](GRAPHICS/ZU050200.GIF)
Note that the following processing is executed during the method cancellation:
-
When a transaction is started, the transaction is timed out forcibly and is marked for rollback.
-
When an SQL statement is executing and the statement cancellation functionality is enabled, the SQL statement is cancelled.
The above mentioned processing is executed even when the method cancellation is not performed because the protected area is executing.
For details on the transaction timeout, see 3.15.8 Transaction timeout and statement cancellation in the uCosminexus Application Server Common Container Functionality Guide.
(3) Operations during method cancellation in Web container and EJB container
If a method is cancelled, ThreadDeath occurs in the threads executing the methods that are to be cancelled. In the Web container and EJB container, catch this ThreadDeath and implement the required processes.
The following section describes the operations when canceling a method in the Web container and EJB container:
(a) Operations in the Web container
The operations differ depending upon the timing when ThreadDeath is thrown.
- When ThreadDeath is thrown during the request process in Web application filter, servlet, or JSP
-
The javax.servlet.ServletException is thrown in the calling filter, servlet, or JSP.
For example, when the servlet is executed in the doFilter method invocation extension of javax.servlet.FilterChain from filter and ThreadDeath occurs during the execution of that servlet, javax.servlet.ServletException is thrown in the invocation of the doFilter method.
Similarly, when the forward method or the include method of javax.servlet.RequestDispatcher is invoked to forward a request to the servlet or JSP, ThreadDeath object is thrown during the getRootCause method of javax.servlet.ServletException.
- When ThreadDeath is thrown during the listener process of the Web application
-
The Web container catches ThreadDeath, but an exception is not thrown for the user program because of which the event that led to the listener is invoked.
For example, when HttpSession is created by invoking the getSession method of javax.servlet.http.HttpServletRequest, the sessionCreated method of javax.servlet.http.HttpSessionListener is invoked. When ThreadDeath is thrown during the execution of this sessionCreated method, the Web container catches the thrown ThreadDeath, but exception is not thrown when invoking the getSession method where the event of HttpSession generation has occurred.
(b) Operations in EJB container
When ThreadDeath is thrown during the EJB method invocation, operations are the same as those when system exception defined in EJB specifications occurs. In the getCause method of the exception returned to calling source, the ThreadDeath object is returned.
(4) Timing of Method cancellation execution
This section explains the timing for canceling the method and the maximum time taken until the method is cancelled.
-
When timeout occurs
In the method cancellation mode for method timeout, when stop thread is set, the method is cancelled when timeout occurs. In the case of settings for message output only, method is not cancelled even when timeout occurs.
The cancellation process of the method where timeout occurs is performed at fixed intervals. Moreover, the method cancellation process is executed asynchronously in a thread that is different from the thread that examines (monitors the timeout) whether the request process in operation has timed out. Hence, the maximum time required from the detection of timeout until the cancellation of method will be equal to the interval of method cancellation process.
The time interval of the method cancellation process is the same as the time interval for monitoring the timeout. For the time interval settings of the method cancellation process, see 5.3.9 Settings for the execution environment.
-
When the method cancellation command is executed
The method is cancelled when method cancellation command is executed during operation.
You check the status of the thread where the timed out method is running, confirm that the method can be cancelled, and then execute the method cancellation command, as and when required.
For details on the procedure for executing method cancellation, see 5.3.10 Flow of monitoring and canceling the execution time of J2EE application.
The method cancellation process is executed asynchronously after command execution. Moreover, the method cancellation process does not influence the time interval of the method cancellation process.
-
When forced termination of J2EE applications is executed
When a J2EE application is terminated forcibly, method cancellation is executed when there are running threads in the J2EE application that is to be stopped.
For details on the forced termination of an application, see 5.5.4 Forced termination process.
The method cancellation process is executed asynchronously after command execution. Moreover, the method cancellation process does not influence the time interval of the method cancellation process.
(5) Notes on method cancellation
During method cancellation, the local variable information is output to the stack trace by default.
Output of the local variable information to the stack trace might affect the performance, so we recommend that you specify -XX:-HitachiLocalsInStackTrace in the JavaVM extension option so that the local variable information is not output to the stack trace during method cancellation.