Sun GlassFish Enterprise Server v2.1.1 High Availability Administration Guide

ProcedureTo Upgrade Components Without Loss of Service

In a clustered environment, a rolling upgrade redeploys an application with a minimal loss of service and sessions. A session can be any replicable artifact, including:

You can use the load balancer and multiple clusters to upgrade components within the Enterprise Server without any loss of service. A component can, for example, be a JVM, the Enterprise Server, or a web application.

A rolling upgrade can take place under light to moderate load conditions. The procedure should be doable in a brief amount of time, about 10-15 minutes per server instance.

Applications must be compatible across the upgrade. They must work correctly during the transition, when some server instances are running the old version and others the new one. The old and new versions must have the same shape (for example, non-transient instance variables) of Serializable classes that form object graphs stored in sessions. Or, if the shape of these classes is changed, then the application developer must ensure that correct Serialization behavior occurs. If the application is not compatible across the upgrade, the cluster must be stopped for a full redeployment.

This approach is not possible if:


Caution – Caution –

Upgrade all server instances in a cluster together. Otherwise, there is a risk of version mismatch caused by a session failing over from one instance to another where the instances have different versions of components running.


  1. Stop one of the clusters using the Stop Cluster button on the General Information page for the cluster.

  2. Upgrade the component in that cluster.

  3. Start the cluster using the Start Cluster button on the General Information page for the cluster.

  4. Repeat the process with the other clusters, one by one.

    Because sessions in one cluster will never fail over to sessions in another cluster, there is no risk of version mismatch caused by a session’s failing over from a server instance that is running one version of the component to another server instance (in a different cluster) that is running a different version of the component. A cluster in this way acts as a safe boundary for session failover for the server instances within it.