Using Servlets with WebLogic Server Clustering

Clustering, discussed in Chapter 13, is important functionality that allows for redundancy and task balancing across multiple pieces of independent hardware and/or processes. For a WebLogic Server deployment, it is necessary to design your hardware environment to accommodate clustering. Similarly, you must design your servlets and Web applications to work well in a cluster environment.

Persisting Session Information

It is highly desirable to protect users' session information in the event of hardware or software failure. For example, if you are storing your shopping carts in the user session, it is desirable to have other nodes in the cluster be aware of the session information in order to protect against the loss of information in the event of failure.

You have three options for session information in a WebLogic Server deployment:

• Do Not Protect Your Session Information. In the event of a failure, all user session information is lost. This is because the session is only stored in a single WebLogic Server instance.

• Protect Your Session Information in the Database. In the event of a failure, all session information is persisted in the database and readily available.

• Protect Your Session Information with In-Memory Replication. In this model, a given session is always directed to the same server in a cluster, typically referred to as the primary. The cluster automatically chooses another server to act as a hot backup to the primary server. This is typically referred to as the secondary server. This node is updated across the network by the primary node after every change to the HttpSession object. In other words, every time you call the setAttribute() or removeAttribute() method, WebLogic Server automatically synchronously updates the copy of the HttpSession on the secondary server. In the event of a failure of either the primary or secondary, a different server in the cluster automatically takes its place to handle the session; thus, the session data will not be lost.

In each case where session information is persisted, only serializable data can be replicated.

Session Protection Performance Implications

There are performance implications when the different types of session protection are used. To illustrate, a test was run using a single-processor Windows NT box running a cluster of two servers under maximum load:

• In-memory replication is 5.5 (389tps/68tps) times faster than database replication.

• Session-state handling for Web connections results in a 66 percent slowdown over static page serving.

• Remote database operations result in a 68 percent slowdown versus local disk database storage.

As demonstrated in Chapter 15, Capacity Planning for the WebLogic Server, the type of session persistence used in an application has an impact upon the hardware required for a given application.

Choosing the Right Level of Protection

Which method of session protection is right for your deployment depends upon your needs. If performance, and not protection of your data, is key, you may choose not to protect your session information. Given that most Web server hardware today has a 99.9 percent up time or better, this is not a bad bet.

For rock-solid protection of session information, database persistence is the best choice. You are absolutely guaranteed not to lose your session information, because every change in the session is enacted as a transaction against the database. Unfortunately, database persistence comes at a cost. JDBC storage of session information can reduce performance substantially.

The mechanism that provides the best of both worlds is in-memory replication. The likelihood that multiple servers go down simultaneously is very low. Yet, the performance costs are minimal. Benchmarks have shown a reasonable amount of overhead for in-memory replication.

Special Considerations for In-Memory Replication

There are a number of special considerations for using in-memory replication of session state:

• In a single server instance, nonserializable data placed into HTTP sessions works fine. Unfortunately, in-memory replication does not work with nonserializable data. You'll incur many debugging headaches to discover that a portion of the data is not being replicated.

• Large, complex objects bring down the server performance. There is a good amount of overhead for serializing/deserializing the data, in addition to the network costs.

• Don't put hash tables, vectors, and so forth in the session because WebLogic Server cannot detect changes to objects in them. WebLogic Server ends up replicating the whole object, even though you changed just one part.

• It is a good practice to make all custom objects implement the serializable interface.

• Data that doesn't change should be made static so that it is not replicated.