Clustering in the Web Tier

Clustering in the EJB Tier

The other areas that can be load balanced and clustered are the components within the application tier. Again, because the J2EE and EJB specifications do not deal with load-balancing issues, the exact components and services that can be clustered is very dependent on your vendor. If load balancing is important for your application, be sure to check with the vendor to see whether it's supported before purchasing an EJB server.

Not all EJB vendors will have complete support for clustering, so this discussion must be a little more generic and really just discuss a superset of features that you'll find across vendors. You will find a few vendors that support all or most of these clustering features in some proprietary manner. The list describes what services can possibly be clustered in the EJB container:

• JNDI

• Stateless session beans

• Entity beans

• Stateful session beans

• JMS

• JDBC connections

Clustering Naming Services

Generally , a clustered naming service will allow the administrator to deploy multiple containers (possibly on multiple machines), which contain identical sets of enterprise beans.

When a client performs a JNDI lookup, the naming service can load balance over the set of enterprise beans associated with that name and select one based on load or last requested . A vendor usually will support multiple algorithms that can be selected at deployment time that determines how the naming service will load balance requests .

When clustering the naming service, if one of the objects fails, the container can substitute it with another in the cluster. This is obviously harder if the object maintained state, but it can still be accomplished. Keep in mind that not all vendors support this feature.

Clustering Stateless Session Beans

Because all instances of the same stateless class are supposed to be identical, clustering stateless objects is generally the easiest and is supported by most vendors.

Upon failure of a stateless session bean in one container, a different stateless session bean in the same or different container can be easily substituted as a replacement with little or no effect on the client. Clustering stateful session beans or entity beans is much harder.

Clustering Entity Beans

Because an entity bean typically represents a set of data from a relational database, it's not generally interchangeable with other entity beans from the container. However, because the data is persisted in the database, a new entity bean that contains the same information can be easily created during a failover condition.

If an entity bean fails during the middle of a transaction, the container will typically assume a rollback and another entity bean instance, possibly in another container, will load the last state of the entity bean from the database.

Note

The presumption of rollback by the container is based on the OTS/JTS specification.

After the other entity bean is loaded with its state from the database, all requests for service will automatically failover to use the other instance.

Clustering Stateful Session Beans

Clustering stateful session beans is by far the hardest to pull off, which is generally why this functionality is not supported by some of the low-end application servers. If it is supported, it's usually one of the last cluster features to be added.

Stateful session beans are tough because they are maintaining state for an individual client and there could be thousands or tens of thousands of clients concurrently in the system. The question becomes how to maintain the state at all times to ensure that if a failure occurs, the system can reload the state and allow the client to continue as if nothing happened .

Typically, vendors choose one of two methods to support clustering of stateful session beans. The two methods differ in where the state is actually maintained. One method is in-memory replication and involves keeping copies of the state somewhere in memory. This is usually much faster, but also subject to some failure as well. The other approach is storing the state in some type of data store. Usually, this persistent store is a relational database. By storing the state in a database, the application server is guaranteed to be able to recover in event of a system failure. Database access can be a performance bottleneck for an application, so this solution isn't always the best one.

Clustering JMS

Some EJB servers are now able to support clustering of JMS queues and topics throughout the cluster. Typically, each instance of the cluster contains a replica of the JMS destination. How and when messages are sent to these duplicate destinations is up to the container. This feature is not supported by all vendors.

Clustering JDBC Connections

Some EJB servers provide limited support for working with JDBC connections in a cluster. Each instance in the cluster would normally set up an identical data source as the other instances, but each instance would be configured to use a different connection pool. This way, if any instance failed, the same data source name would work in the other clustered instances.

Caution

You must be careful with connection pools because EJB servers typically don't provide any load balancing within the pools. If one of your connection pools runs out of connections, the clustered instance might still receive requests, even though no connections are available.