17.3.4 System operations during node switching
This subsection describes the system operations during the node switching.
- Organization of this subsection
(1) Inheriting the HTTP session information
When you do not use the session failover functionality, the HTTP session information#1 managed by the Web container and the attribute information#2 specified in ServletContext remains only in the memory of the J2EE server, and this information is not shared between the executing node and the standby node. After the nodes are switched, the HTTP session information is lost. Therefore, invalid operations might be executed in the Web applications and Web client where the session is already running. In order to prevent this, you specify settings in applications so that if inconsistency occurs in the session information, appropriate action can be taken.
When using the session failover functionality, you can maintain the HTTP session information even after the node switching. However, you can only maintain the session information that is inherited with the session failover functionality.
In order to maintain the session after node switching, you must uniquely set up the session in the applications so that the session is managed by DBMS, and can be referenced from both the executing node and the standby node.
- #1
-
Indicates information stored in the javax.servlet.http.HttpSession object acquired using the javax.servlet.http.HttpServletRequest#getSession method.
- #2
-
Indicates information stored in the javax.servlet.ServletContext object acquired using the javax.servlet.ServletContext#getServletContext method.
(2) Inheriting the EJB session information
The session information# managed by the EJB container is only in the memory of the J2EE server, and therefore, once the node is switched, the session information is lost (the session information is not shared between the executing node and standby node). Therefore, normal operations might not continue in the EJB client that is already running the session. If the session information is lost, you are required to design the EJB client so that the process from the Home lookup will re-execute.
Note that the same problem occurs in the CTM environment.
- #
-
Indicates the object information of the home interface and component interface.
(3) Inheriting the transaction information
The inheriting of the transaction information depends on the types of transaction. The inheriting of the transaction information for local transaction and global transaction is as follows:
(a) In the local transaction
In a local transaction, the transaction information is not inherited when the nodes are switched.
When the system is down due to failure and if node switching occurs due to process failure in the J2EE server, both commit and rollback are not executed for a running transaction.
Alike planned node switching, when the J2EE server terminates normally, the transaction does not remain in the running state.
(b) In the global transaction
In a global transaction, the transaction inherited after node switching is used to execute the transaction recovery process when the J2EE server starts. As a result, the appropriate process from commit or rollback is implemented.
(4) Operations of the Administration Agent
In the Administration Agent, information is not inherited directly between the executing node and the standby node. After node switching, the logical server coded in the starting script of the Administration Agent will start. For details on the starting script of Administration Agent, see 17.6.5 Creating a shell script file.
(5) Key information output to the Trace based Performance Analysis
The key information for identifying the series of processes is provided in the information output to the Trace based Performance Analysis. This key information includes the IP address used for creation. When there is a host with several IP addresses, the key information includes one of the IP addresses of that host. Therefore, in the Trace based Performance Analysis that is output to the executing node host, the stationary IP address (IP address that does not move to other nodes by node switching) and the alias IP address (IP address dynamically allocated by cluster software) might be included as the key information. Note that subsequently, the IP address included in the key information might change before or after the node switching.
For the key information that is output to the Trace based Performance Analysis, see 7.2 Overview of the trace based performance analysis in the uCosminexus Application Server Maintenance and Migration Guide.