When a client requests for bean A through lookup or injection, a Naming Server randomly selects and returns one of the three beans. This implies that each of the three beans will receive an equal share of requests. Thus, the client can expect to increase the maximum system performance by three times than when having only one engine that services all the requests, not counting the small overhead associated for load balancing.

Based on the bean type, the client operates as follows:

The following table summarizes the load balancing mechanism for each EJB version and engine method.

To perform load balancing for stateless EJB 3.x engines in the same way as EJB 2.x engines even at the expense of compromising performance, refer to "6.3. Configuring EJB Clustering" and use the clustering method for JEUS 7 and earlier versions.

Failover is the ability to recover from a failure in a single EJB service (e.g., OS crash, network disruption, or severe EJB engine failure).

There are two types of recoveries that the JEUS system can perform:

The two scenarios differ by when an error condition is detected. The first method is used for a situation when a remote business method has not been invoked yet, and the second is used for a situation when the bean is already processing the request.

An Idempotent method is a getter method that has no side effects. This means that we can invoke an idempotent method with the assurance that no states (e.g., instance variables, database fields, etc.) are changed during its execution.

An idempotent method can be used to deal with the second recovery issue of "6.2.2. Failover (EJB Restoration)": if a method is idempotent, we can safely re-invoke it on a different bean even if the first attempt to invoke the method failed during execution. However, if a method is not idempotent, there is nothing we can do in such a scenario. It is better to throw an exception than re-executing the method when a runtime error occurs. Hence, EJB failover performs better when more Idempotent methods are used. The status of the business method must be identified before configuring it.

A stateful session bean uses JEUS session manager to back up sessions. Generally, session state changes according to each business method invocation. Thus the session manager requests for a back up of sessions to JEUS session manager whenever a method is called and the result is returned in JEUS. This backup process is also called Session replication.

JEUS session manger can copy sessions either synchronously or asynchronously, which is called a replication mode in JEUS.

Both methods have pros and cons, thus JEUS lets the user select the mode according to the bean and business method characteristics. The user also can specify not to use session replication. For more information, refer to "6.3. Configuring EJB Clustering".

Configure classes or methods of a clustered bean by using annotation as follows.

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(useDlr = true)
@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;
   }
 ...
}

Descriptions for each class are as follows:

The following configuration for each clustered bean can be configured inside the <clustering> tag in the JEUS EJB module DD file (jeus-ejb-dd.xml).

<jeus-ejb-dd>
        . . .
    <beanlist>
        . . .
        <jeus-bean>
            <ejb-name>counter</ejb-name>
            <export-name>COUNTER</export-name>
            . . .
            <clustering>
                <enable-clustering>true</enable-clustering>
                <use-dlr>true</use-dlr>
                <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>

Descriptions for each tag are as follows:

In order for the previously defined bean clustering to work, you must consider these issues.

In order to execute stateful session beans in a clustered environment, node clustering and session manager configurations are additionally required.

The following describes the passivation timeout, which is one of the session manager setting items. For more information about other items, refer to JEUS Session Management Guide. "2.10.3. Distributed Session Server Configuration Details"