One of the greatest strengths of Java Platform 2, Enterprise Edition (J2EE) application servers is the ability to scale solutions to meet increased performance and availability demands. The inherent clustering and failover capabilities built into products such as the IBM WebSphere Application Server Network Deployment Edition take care of most of the dirty work; however, there are important application considerations that can't be overlooked. If an application isn't designed for cluster awareness, functional or performance issues can surface when deploying your application to a cluster.

Expecting your application to run only in a single server Java Virtual Machine (JVM) is self-limiting, and with a little more upfront work, you can ensure cluster readiness, and be more confident that your application will scale when the need arises. This paper discusses design and implementation considerations for cluster awareness. While many of these best practices are the tried-and-true best practices for any J2EE application, you'll see how essential they become when you move to a cluster. In addition, there are more subtle considerations - often realized the hard way - that cause an application to fail in a cluster.

When an application is moved into a clustered environment, multiple versions of the application are now executing, with some type of workload management distributing and balancing the work. The application may be running on different JVMs on the same physical server or across different servers. Data, resource sharing, and timing have to be carefully designed. Subsequent requests to the same application may end up executing on different servers.

This article discusses the following areas that require special consideration when designing your application for cluster awareness.

1. Follow user session state best practices
2. Design configuration data access to avoid local files and in-memory updates
3. Design application and database for data concurrency and idempotence
4. Maximize local object accesses within tiers
5. Leverage messaging to enable background and/or batch processing
6. Design and partition caches
7. Configure shared resources appropriately
8. Use application server provided workload management and replication
9. TEST, TEST, TEST

Follow User Session State Best Practices
HTTP is a stateless protocol requiring the user state to be stored on the server side using HTTP sessions and other J2EE components such as Stateful Session EJBs. When your application is moved into a clustered environment, different requests from the same user may go to different application servers. This means that all application servers need to have access to these types of session data to maintain availability across user requests. Application servers like WebSphere provide a sophisticated infrastructure to support sharing HTTP session data across servers. This includes performance optimizations in the workload routing and caching so that under normal operating situations, the HTTP session object is actually resident on the server that the request is sent to, eliminating the need for the runtime to repopulate the session object from the database or shared memory.

Though your application server may provide algorithms that minimize the need for a session to be repopulated from the database, any HTTP session replication and failover capability requires adherence to several best practices to perform effectively:

1. A session should be small and avoid complex object graphs
2. Session objects must be serializable
3. References to unnecessary objects that are dependent on the current runtime environment should be avoided
4. Session wrappers must call the set attribute appropriately

Some techniques that can be helpful in keeping your session small:

• Make sure it's state data, not history
• Make sure it's user state data, not application data that's not user-specific
• Keep a key to the data
• Re-create the data on failover rather than storing it in the database

An example of a technique using transient variables to enable WebSphere to serialize objects selectively and re-create data is discussed by Brown and Botzum in "Improving HttpSession Performance with Smart Serialization."1

Design Configuration Data to Avoid Local Files and In-Memory Updates
Another type of data that's common is application configuration data or properties. Simple single-server solutions often read configuration data from a local file and store it in a Java object. This is commonly a set of static fields or a singleton. The configuration data is then accessed and updated by the application and may be persisted back to the local file.

These techniques don't work in a cluster. Remember, the configuration data needs to be accessible by the application running on different servers, and any changes have to be visible to all running copies of the application.

Common techniques that work in a cluster include using a database or LDAP server to keep the configuration data. If your design uses a file system, you'll have to set up file replication techniques using ftp or a shared file system. Remember, if you use any of these techniques, you'll need to document the mechanism your application requires since these are not capabilities supplied by the application server runtime.

Design Application and Database for Data Concurrency and Idempotence
Once an application is clustered, there are now multiple copies of the application working against the same shared runtime data. This will usually increase the amount of concurrent access to data. It can also mean that the same user can login and make requests simultaneously from multiple browsers. This increased data concurrency can lead to invalid requests and potential data corruption. When you design your application for database access, appropriate levels of locking within transactions are required to prevent data corruption while also minimizing the lock levels to prevent deadlocks. Concurrent access deadlock problems may not show up until you move to a cluster.

For example, Message Driven Beans (MDBs) that access data in a random order with exclusive locks will work in a single application server environment, but will often be deadlocked when moved to a cluster. MDBs need to have fixed order for any data or tables that are locked exclusively. This can be done by sorting the data before accessing. Another alternative when record processing order doesn't matter is to partition the queues, allowing multiple consumers of the requests.

Another challenge for a clustered application is ID generation for database keys. If high performance is needed, one common design pattern is to add a table to the database that's used to allocate pools of keys for each cluster.