IIOP Load Balancing in a Cluster

With IIOP load balancing, IIOP client requests are distributed to different
server instances or name servers. The goal is to spread the load evenly across
the cluster, thus providing scalability. IIOP load balancing combined with
EJB clustering and availability features in the Sun Java System Application
provides not only load balancing but also EJB failover.

When a client performs a JNDI lookup for an object, the Naming Service
creates a InitialContext (IC) object associated with a particular server instance. From
then on, all lookup requests made using that IC object are sent to the same
server instance. All EJBHome objects looked up with that InitialContext are hosted on the same target server. Any bean references
obtained henceforth are also created on the same target host. This effectively
provides load balancing, since all clients randomize the list of live target
servers when creating InitialContext objects. If the target
server instance goes down, the lookup or EJB method invocation will failover
to another server instance.

For example, as illustrated in this figure, ic1, ic2, and ic3 are three
different InitialContext instances created in Client2’s
code. They are distributed to the three server instances in the cluster. Enterprise
JavaBeans created by this client are thus spread over the three instances.
Client1 created only one InitialContext object and the bean references from
this client are only on Server Instance 1. If Server Instance 2 goes down,
the lookup request on ic2 will failover to another server instance (not necessarily
Server Instance 3). Any bean method invocations to beans previously hosted
on Server Instance 2 will also be automatically redirected, if it is safe
to do so, to another instance. While lookup failover is automatic, Enterprise
JavaBeans modules will retry method calls only when it is safe to do so.

IIOP Load balancing and failover happens transparently. No special steps
are needed during application deployment. Adding or deleting new instances
to the cluster will not update the existing client’s view of the cluster.
You must manually update the endpoints list on the client side.