+

Search Tips   |   Advanced Search

Stateful session bean failover for the EJB container

We can use WebSphere Application Server to construct applications that use stateful session beans that are not limited by unexpected server failures. The product uses the functions of the Data Replication Service (DRS) and Workload Management (WLM) so we can enable stateful session bean failover.

Because you might not want to enable failover for every stateful session bean installed in the EJB container, we can override the EJB container settings at either the application or EJB module level. We can either enable or disable failover at each of these levels. For example, consider the following situations:

For information about enabling stateful session bean failover from the console, see the following topics:


Stateful session bean activation policy with failover enabled

We can specify an activation policy for stateful session beans during application assembly. It is important to consider 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 we configure the bean with an active once activation policy, which is the default, the bean is not passivated promptly enough to be useful for stateful session bean failover. Therefore, when you enable failover, the EJB container ignores the configured activation policy for the bean and automatically uses the activate at transaction boundary activation policy. This action ensures that the bean is passivated and its data is replicated whenever it is enlisted in a transaction that completes.

When DRS is given data to replicate, DRS replicates the data to N-1 application servers, where N is the number of available replicas. If the creating server, and all the servers holding the backup copies of the data fail or are stopped, the replicated data is lost unless the DRS consumer re-replicates the data.gotcha


Stateful session bean use of container managed units of work or bean managed units of work with failover enabled

The relevant units of work in this case are transactions and activity sessions. The product supports stateful session bean failover for container-managed transactions (CMT), bean-managed transactions (BMT), container-managed activity sessions (CMAS), and bean-managed activity sections (BMAS). However, in the container managed cases, preparation for failover only occurs if you send a request for an enterprise bean method invocation that results in no connection to the server. Also, if the server fails after it receives and acknowledges a request, 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 Common Object Request Broker (CORBA) exception and minor code that specifies that transparent failover must not occur because the failure happened during execution of a unit of work. We must write the application 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.

For more information, see the Corba minor codes topic.

For more information, see the Workload management for all platforms except z/OS topic.

The same is true for bean-managed units of work like transactions or activity sessions. However, bean-managed work introduces a new possibility that must 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 behavior on the new server and initiates an exception. This exception occurs under the following scenario:

  1. A method of a stateful session bean that uses bean-managed transaction or activity session calls the begin method on a UserTransaction it obtained from the SessionContext object. 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.

  2. After invocation of the method starts, the EJB container suspends the work that was 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.

  3. 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.

  4. 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.

This process indicates 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 difference is that an exception occurs for bean-managed units of work.


Application design considerations

Consider the following information when designing applications that use the stateful session bean failover process:


(zos) For z/OS users only

Stateful session bean failover on WebSphere Application Server Network Deployment for z/OS is slightly different than that on the WAS Network Deployment product. In addition to the failover solution discussed here, z/OS users can also enable failover among servants in an unmanaged server. For more information, refer to the topics:

Because the z/OS product has a control region and servant regions and the WAS Network Deployment product does not, there is one failover scenario that is unique to z/OS, which is failover from one servant region to another servant region (loss of a servant without loss of the controller).

If we use the HFS-based technique on z/OS, then continue with that technique.

In an unmanaged z/OS server, stateful session bean failover among servants can be enabled. Failover only occurs between the servants of a given unmanaged server. If an unmanaged z/OS server has only one servant, then enabling failover has no effect. An unmanaged z/OS server that has failover enabled does not fail over to another unmanaged z/OS server. To enable failover in an unmanaged server, refer to Enable failover of servants in an unmanaged server.


Subtopics


Related information:

  • uejb_timerservice.dita