What is Failover Mechanism?

Servers use intelligent wrappers around regular stubs to provide failover capability. Failover mechanism provides high application availability to end users. The application server ensures that the clients attached to the failed node are seamless moved to a running node in case of a node failure. Failover is accomplished by using intelligent (cluster aware) wrappers around regular stubs. The wrappers contain information required to facilitate a smooth failover. The wrappers are completely transparent to the client and require no special programming on the client’s side. Since the wrappers use normal stubs, no special RMI compiler is required.

Failover occurs for each bean type as:

• Stateless session beans
• Stateful session beans
• Entity Beans

What are Stateless Session Beans?

For stateless session beans, the wrapper creates a new instance of the bean on a new EJB node and executes the call on that bean instance. The bean instance is re-created at an alternate node, giving full recovery.

What are Stateful Session Beans?

For stateful session beans, failover is in-memory or is achieved with the help of a database. This information is taken during cluster configuration. During deployment of the application for stateful session beans, the deployer can specify the methods of the bean that change state. This information is used by the EJB container to persist the state of the bean at the end of specified methods in-memory or to a database. The database information is taken at the time of configuring the cluster. If the session state is maintained in-memory, the state gets replicated on all the other nodes.

In case of database persistence, all nodes of the cluster use a single database or table to persist the stateful session beans. When an EJB node on which a stateful session bean is created goes down, the wrapper creates a new instance of the bean on a different EJB node. It also attaches the passivated bean instance to the created stateful session bean.

Stateful beans are always persisted after creation. The ejbCreate() is treated as a method that changes the state of a bean. Before persisting the state, the container passivates the bean instance making it serializable. After persistence, ejbActivate() is called. The bean must ensure that it is in a serializable state after making a call to ejbPassivate() and must bring itself back to working state after an ejbActivate() call.

Apart from similar recovery of bean instance on an alternate node, state (bean data) has to be restored on the newly created bean instance. This means that bean state is persisted. Pramati Server persists bean state to the database. The deployer can specify bean methods that result in the change of state. The wrapper class takes care of the persistence as and when bean state actually changes (not at regular intervals).

What are Entity Beans?

For entity beans, the wrapper recreates a new instance of the bean on a different node through an ejbFindByPrimaryKey() method call on the new node. The last committed data is loaded into the bean and the bean is returned to the client for use.

Bean state is loaded from the persistent storage. When a partially executed client call fails, the wrapper handles creation of bean instance on alternate node and places the call again. By default, the state of an entity bean is persisted. So, in case of a failover, the bean is activated on another node and its state synchronized.

© Pramati Technologies 2007	Runs on Pramati Server | Feedback | Legal