You 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 you can enable stateful session bean failover.
You 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 you 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.
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. You 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.
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.
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.
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, your application receives unpredictable results.
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. If you need 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.