Show TOC Start of Content Area

Function documentation Failover for Enterprise Beans  Locate the document in its SAP Library structure

Use

One of the mechanisms of the J2EE Engine to provide a stable environment for the enterprise applications running on it is the failover concept. The system performs this by serializing all HTTP and stateful sessions and storing them in files or in the database.

Enterprise beans that are involved in an HTTP session are serialized by the EJB Container when the HTTP session is serialized. Stateful session beans, which are accessed through RMI-P4, can use the stateful session failover provided by the Session Failover Service.

The failover, performed by the system, is transparent for the clients.

Integration

The failover is not enabled by default; therefore, if you want to use this function, you must enable it first.

To use the HTTP failover, you must enable failover for the entire application. You cannot enable HTTP failover for your enterprise beans only, so you should be careful when specifying failover for applications that involve large objects in the HTTP sessions, because in this case the application overhead becomes significant. For more information about how to enable HTTP failover for your enterprise application, see Enabling and Disabling HTTP Failover.

You can enable the stateful session failover for a specific stateful session bean in the EJB application. For more information, see Enabling Stateful Session Failover.

For more information about how to specify the persistent storage where the serialized data will be stored, see Specifying the Failover Persistent Storage.

Features

HTTP Failover

Stateless Session Enterprise Beans

Stateless session beans survive as long as the client session survives, but they do not preserve their state between different calls. When the EJB Container serializes a stateless session bean reference, it stores an ID mapped to the session of that bean. When deserializing the stateless bean, the session bean container is identified by the stored ID and the EJB Container calls the create() method of the bean’s home interface, that is, it creates a session represented by a new EJBObject or EJBLocalObject. The client obtains a new reference and uses the new instance, but since stateless beans have no state, each client request can be processed by a different instance without any data loss.

Stateful Session Enterprise Beans

Stateful session beans hold a state in the corresponding bean instance; therefore in order to preserve the state, the corresponding instance is serialized. When a new reference to the stateful session bean is received, the EJB Container creates a new EJBObject or EJBLocalObject in a new stateful session, deserializes the failed-over instance and assigns it to the EJBObject or the EJBLocalObject.

Entity Enterprise Beans

The J2EE Engine always stores the last committed state of an entity bean in the database. Therefore, the state of the entity bean is not serialized. Instead, the EJB Container creates an EntityBeanReference object for each received reference to an entity bean. This object is serialized by its ID and PK (primary key). When the server fails, the new server deserializes the entity bean reference, that is, it locates the EJB Container using the object’s ID, and calls the bean’s createEJBObject(PK) or createEJBLocalObject(PK) method. When the entity object is accessed, it loads the persistent data from the database.

Programming Requirements

The stateful bean instances, like the HTTP session objects, must not contain non-serializable objects other than the following:

Otherwise, the EJB Container will not be able to serialize the bean, and the whole HTTP session will not be serialized.

Failover and JDBC Connections

JDBC connections are non-serializable objects. Therefore, they must be closed and all references to them must be set to null before the Session Failover Service tries to serialize an HTTP session that contains JDBC connections.

·        Stateless Session Enterprise Beans

There is no need to store JDBC connections for stateless session beans because their instances are not serialized.

·        Stateful Session Enterprise Beans

If your stateful session bean keeps a reference to a connection object between method calls, you must specify the <keeps-open-resources> element in ejb-j2ee-engine.xml. Thus, during the bean’s serialization and deserialization, the EJB Container will invoke the bean’s ejbPassivate() and ejbActivate() methods. The bean must close its connection in its ejbPassivate() method and must set its references to null.

·        Entity Enterprise Beans

There is no need to store JDBC connections for entity beans because their instances are not serialized.

Stateful Session Failover

The stateful session failover is transparent for the clients – they invoke methods on the home or the remote interface of the bean. The requests are processed as if there are no problems with the cluster because the requests are redirected to an active cluster node, and this is invisible for the client. In order to handle situations when a server crashes while executing an operation on the bean, clients must modify their code as com.sap.engine.services.rmi_p4.P4ConnectionException will be thrown. Clients must catch this exception when invoking a bean’s business method and try to repeat the invocation. Thus, the call will be redirected to an active server in the cluster and the state of the session will be restored from the persistent storage.

If container-managed transaction demarcation is used, the state of the session will be serialized in the persistent storage at the end of each transaction. If there is no transaction (the transaction attribute is one of the following: TX_NEVER, TX_NOT_SUPPORTED, and TX_SUPPORTS), the bean instance will be serialized after the business method. When bean-managed transaction demarcation is used, the bean instance is stored after each business method.

The stateful session failover is specified in the additional deployment descriptor – ejb-j2ee-engine.xml. The EJB Container generates the implementation of the remote EJBHome and EJBObject interfaces as redirectable objects. When a server crashes and a method is invoked on such a redirectable object, the call will be redirected to another server process in the cluster. The EJB Container reads the replicated session state, that is, the serialized bean instance, from the persistent storage and creates a new session on the new server process. This is transparent to the client and even though there is a new session on the new server process, the bean instance will have the last preserved state – that is, after the last committed transaction or the last successfully executed business method.

Passivation and Failover

The passivation and the failover for stateful session beans use the mechanism provided by the Session Failover Service. A stateful session bean can use both passivation and failover at the same time – the two features are integrated to work together as well as separately. Since passivation is not executed in a transaction, if failover is used as well, the passivation does not serialize anything. It just relies on the failover. If only passivation is used, then it serializes the bean instance and afterwards, in activation state, it deserializes it from the persistent storage. The failover does not depend on the passivation at all.

 

See also:

Failover System in the Administration Manual

HTTP Sessions and Failover of Web Applications

 

 

End of Content Area