In order to use the failover and load balancing functions in EJB, individual beans may be deployed across several EJB engines to form a cluster. Clustering is accomplished on the component level (individual beans) and may be used by Stateless/Stateful session beans and entity beans. A Message Driven Bean (MDB) is not a clustering target.

JEUS EJB clustering has the following two functions:

The following figure explains two major functions of EJB clustering, load balancing and failover.

[Figure 6.1] EJB Clustering Architecture

If you deploy modules that need clustering, they are all bound to the same name in the Naming Service. Using this name, client can perform load-balancing and failover. Therefore, even if you deploy the same module by binding it to the Naming Server using a different name, the module will not be included in the cluster.

The following explains major functions of EJB clustering.

EJB clustering can be configured either by using annotation in the bean class or the jeus-ejb-dd.xml file. Configuration items for clustering include the Bean to be configured, idempotent methods of the bean, and session replication mode of each bean or method.

This section shows how to configure annotation and descriptor (xml) for clustering through examples.

package ejb.basic.statelessSession;

import javax.ejb.Stateful;
import jeus.ejb.Clustered;
import jeus.ejb.Replication;
import jeus.ejb.ReplicationMode;

@Stateful(name="counter", mappedName="COUNTER")
@Clustered
@Replication(ReplicationMode.SYNC)
@CreateIdempotent
public class CounterEJB implements Counter, CounterLocal {
   private int count = 0;

   public int increaseAndGet() {
      return ++count;
   }

   @Replication(ReplicationMode.NONE)
   public void doNothing(int a, String b) {
   }

   @Idempotent
   public int getResult() {
      return count;
   }

   @Idempotent
   @jeus.ejb.Replication(ReplicationMode.ASYNC)
   public int getResultAnother() {
      return count;
   }
 ...
}

<jeus-ejb-dd>
        . . .
    <beanlist>
        . . .
        <jeus-bean>
            <ejb-name>counter</ejb-name>
            <export-name>COUNTER</export-name>
            . . .
            <clustering>
                <enable-clustering>true</enable-clustering>
                <ejb-remote-idempotent-method>
                    <method-name>getResult</method-name>
                </ejb-remote-idempotent-method>
                <ejb-remote-idempotent-method>
                    <method-name>getResultAnother</method-name>
                </ejb-remote-idempotent-method>
                <create-idempotent>true</create-idempotent>
                <replication>
                    <bean-mode>sync</bean-mode>
                    <methods>
                        <method>
                            <method-name>doNothing</method-name>
                            <method-params>
                                <method-param>int</method-param>
                                <method-param>java.lang.String</method-param>
                            </method-params>
                            <mode>none</mode>
                        </method>
                        <method>
                            <method-name>getResultAnother</method-name>
                            <method-params>
                                <method-param>void</method-param>
                            </method-params>
                            <mode>async</mode>
                        </method>
                    </methods>
                </replication>
            </clustering>
            . . .
        </jeus-bean>
         . . .
    </beanlist>
    . . .
</jeus-ejb-dd>

A client may use the EJB reference (Stub) by caching it or using injection, instead of doing a look up each time. In this case, failover may not be performed even though there is another alive end-point. This may occur when MSs, that were alive in the EJB end-point list at the time of the lookup, are not alive, and only new MSs that started after the lookup are alive.

EJB references are looked up internally at the time of the failover, and a new EJB reference is sent to the client. However, if all deployed MSs are terminated when you are doing a lookup of an EJB reference that is in use, failover cannot be performed even though there is a new EJB end-point that is deployed after the lookup and is able to provide the service.

In the previous case, the termination of existing MSs means that the nodes are abnormally terminated or shut down, or an EJB end-point is undeployed and cannot provide the service. The deployment of a new EJB end-point can mean that the time when the new MS was included to a cluster was too late (when EJB reference is already looked up and used), downed MS was restarted too late, or the undeployed EJB end-point was redeployed too late.

This may occur when two MSs are used for active/backup clustering. The following is an example scenario.

A single EJB engine exists in each MSs: A, B, and C. A client looks up EJB references for the first time and caches them.

In this case, when EJB reference of C is looked up, EJB end-point of B was undeployed and was redeployed after EJB on C was looked up. When C was terminated, B was still alive, but failover was not performed. However, if B was not deployed or undeployed, but was abnormally started or terminated, failover is performed. This is because the status of the engine for rebooting is checked for abnormal terminations.

It is possible to avoid the previous situation, if a new EJB Reference is looked up again and a new end-point list is obtained.