Stateful session bean failover for the EJB container
WAS v6.1 uses the Data Replication Service (DRS) and Workload Management (WLM) to enable stateful session bean failover.
You can enable or disable failover at the application or EJB module level....
- To enable failover for all applications except for a single application
- Enable failover at the EJB container level
- Override the setting at the application level to disable failover on the single application.
- To enable failover for a single installed application
- Disable failover at the EJB container level
- Override the setting at the application level to enable failover on the single application.
- To enable failover for all applications except for a single module of an application
- Enable failover at the EJB container level
- Override the setting at the module application level to disable failover on the single module.
- To enable failover for a single installed EJB module
- Disable failover at the EJB container level
- Override the setting at the EJB module level to enable failover on the single EJB module.
Stateful session bean activation policy with failover enabled
Application assemblers can specify activation policies for stateful session beans.
Note that the only time the EJB container prepares for failover, by replicating the stateful session bean data using DRS, is when the stateful session bean is passivated. If you configure a bean with an activate once policy, the bean is essentially never passivated.
If you configure the activate at transaction boundary policy, the bean is passivated whenever the transaction that the bean is enlisted in completes.
For stateful session bean failover to be useful, the activate at transaction boundary policy is required.
Rather than forcing you to edit the deployment descriptor of every stateful session bean and reinstall the bean, the EJB container simply ignores the configured activation policy for the bean when you enable failover. The container automatically uses the activate at transaction boundary policy.
Stateful session bean use of container or bean managed units of work with failover enabled
The relevant "units of work" in this case are transactions and activity sessions.
WAS supports stateful session bean failover for...
However, in the container managed cases, preparation for failover only occurs if trying to send a request for an enterprise bean method invocation results in no connection to the server. Also, if the server fails after a request is sent to it and acknowledged, failover does not occur. When a failure occurs in the middle of a request or unit of work, WLM cannot safely fail over to another server without some compensation code being executed by the application. When that happens, the application receives a CORBA exception and minor code telling it that transparent failover could not occur because the failure happened during execution of a unit of work.
- Container managed transactions (CMT)
- Bean managed transactions (BMT)
- Container managed activity sessions (CMAS)
- Bean managed activity sections (BMAS)
The application should be written to check for the CORBA exception and minor code, and compensate for the failure. After the compensation code executes, the application can retry the requests and if a path exists to a backup server WLM routes the new request to a new primary server for the stateful session bean.
The same is true for bean managed units of work (transactions or activity sessions). However, bean managed work introduces a new possibility that needs to be considered.
For bean managed units of work, the failover process is not always able to detect that a BMT or BMAS started by a stateful session bean method has not completed. Thus, it is possible that failover to a new server can occur despite the unit of work failing during the middle of a transaction or session. Because the unit of work is implicitly rolled back, WLM behaves as if it is safe to transparently fail over to another server, when in fact some compensation code might be required. When this happens, the EJB container detects this on the new server and initiates an exception. This exception occurs under the following scenario:
- A method of a stateful session bean using bean managed transaction or activity session calls begins on a UserTransaction it obtained from the SessionContext.
The method does some work in the started unit of work, but does not complete the transaction or session before returning to the caller of the method.
- After invocation of the method started in step 1, the EJB container suspends the work started by the method. This is the action required by Enterprise JavaBeans specification for bean managed units of work when the bean is a stateful session bean.
- The client starts several other methods on the stateful session bean.
Each invocation causes the EJB container to resume the suspended transaction or activity session, dispatch the method invocation, and then suspend the work again before returning to the caller.
- The client calls a method on the stateful session bean that completes the transaction or session started in step 1.
This scenario depicts a sticky bean managed unit of work.
The transaction or activity session sticks around for more than a single stateful session bean method. If an application uses a sticky BMT or BMAS, and the server fails after a sticky unit of work completes and before another sticky unit of work starts, failover is successful. However, if the server fails before a sticky transaction or activity session completes, the failover is not successful. Instead, when the failover process routes the stateful session bean request to a new server, the EJB container detects that the failure occurred during an active sticky transaction or activity session. At that time, the EJB container initiates an exception.
Essentially, this means that failover for both container managed and bean managed units of work is not successful if the transaction or activity session is still active. The only real difference is the exception that occurs.
Application design Considerations
You should consider the following when designing applications that use the stateful session bean failover process:
- To avoid the possibility described in the section above, you are encouraged to write your application to configure stateful session beans to use CMT rather than BMT.
- If you desire immediate failover, and your application creates either an HTTP session or a stateful session bean that stores a reference to another stateful session bean, then the administrator must ensure the HTTP session and stateful session bean are configured to use the same DRS replication domain.
- Do Not use a local and a remote reference to the same stateful session bean.
Normally a stateful session bean instance with a given primary key can only exist on a single server at any given moment in time. Failover might cause the bean to be moved from one server to another, but it never exists on more than one server at a time. However, there are some unlikely scenarios that can result in the same bean instance (same primary key) existing on more than one server concurrently. When that happens, each copy of the bean is unaware of the other and no synchronization occurs between the two instances to ensure they have the same state data. Thus, your application receives unpredictable results.
To be sure to avoid this situation remember that with failover enabled, your application should never get both a local (EJBLocalObject) and remote (EJBObject) reference to the same stateful session bean instance.
Sub-topics
Stateful session beans failover settings (applications)
Stateful session beans failover settings (EJB modules)Enable stateful session bean failover with the EJB container panel Enable stateful session bean failover with the enterprise applications panel Enable stateful session bean failover with the EJB modules panel.