Stateful session bean failover for the EJB container

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 we 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:

• You want to enable failover for all applications except for a single application. To do this, we enable failover at the EJB container level and override the setting at the application level to disable failover on the single application.

• You want to enable failover for a single installed application. To do this, disable failover at the EJB container level and then override the setting at the application level to enable failover on the single application.

• You want to enable failover for all applications except for a single module of an application. To do this, enable failover at the EJB container level, then override the setting at the module application level to disable failover on the single module.

• You want to enable failover for a single installed EJB module. To do this, disable failover at the EJB container level and then override the setting at the EJB module level to enable failover on the single EJB module.

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

• Enable or disable stateful session bean failover with the EJB container panel
• Enable or disable stateful session bean failover with the enterprise applications panel
• Enable or disable stateful session bean failover with the EJB modules panel

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

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 Architecture (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.

See 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, WLMust 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 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:

• To avoid the exception described in the previous section, we are encouraged to write the application to configure stateful session beans to use container-managed transactions (CMT) rather than bean-managed transactions (BMT).

• If we want failover, and the 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 data replication service (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, some unlikely scenarios 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 existence of the other and no synchronization occurs between the two instances to ensure they have the same state data. Thus, the application receives unpredictable results.

  To avoid this situation, we must remember that with failover enabled, the application must never get both a local (EJBLocalObject) and remote (EJBObject) reference to the same stateful session bean instance.

• Avoid the use of remote asynchronous methods on stateful session beans.

  When an asynchronous method is called, the asynchronous method request is queued by the remote server, and a Future object is returned to the client. Because the method request is only queued on the server with the stateful session bean instance, the Future object is bound to that server and does not fail over. To use remote asynchronous methods for stateful session beans, write the application to detect when a call to the Future object fails and make a synchronous call to the stateful session bean to determine whether the transaction that was started by the asynchronous method completed successfully.

• Avoid referencing non-persistent EJB timers in stateful session bean instance when failover is enabled.

  If a stateful session bean includes a handle to an automatically or programmatically created non-persistent timer instance, the handle is invalid after the stateful session bean fails over and the javax.ejb.NoSuchObjectLocalException exception occurs when this handle is used. If the application needs to reference non-persistent timers in stateful session beans, write the application to account for the invalid handle.

  Handles to automatically or programmatically created persistent timers in stateful session beans, will failover and can be used after a stateful session bean failover.

(ZOS) For z/OS users only

Stateful session bean failover on WAS ND for z/OS is slightly different than that on the WAS ND product. In addition to the failover solution discussed here, z/OS users can also enable failover among servants in an unmanaged server. Refer to the topics:

• Multiple servants

• Set up peer restart and recovery
• Clusters on which stateful session beans might be deployed

Because the z/OS product has a control region and servant regions and the WAS ND 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 Enabling failover of servants in an unmanaged server.

Subtopics

• Stateful session beans failover settings (applications)
  Each EJB container provides a method for stateful session beans to fail over to other servers. Use this method to specify whether failover occurs for the stateful session beans in this application. We can also override the stateful session bean failover settings on a particular module.
• Stateful session beans failover settings (EJB modules)
  Each EJB container provides a method for stateful session beans to fail over to other servers. Use this method to specify whether failover occurs for the stateful session beans in this module. We can also override the stateful session bean replication settings of the parent object for this module.
• Stateful session beans failover settings (applications)
  Each EJB container provides a method for stateful session beans to fail over to other servers. Use this method to specify whether failover occurs for the stateful session beans in this application. We can also override the stateful session bean failover settings on a particular module.
• Stateful session beans failover settings (EJB modules)
  Each EJB container provides a method for stateful session beans to fail over to other servers. Use this method to specify whether failover occurs for the stateful session beans in this module. We can also override the stateful session bean replication settings of the parent object for this module.

uejb_timerservice.dita