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:
stateful session bean
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:
You change the schema of the high-availability database (HADB). For more information, see Chapter 3, Administering High Availability Database
The HADB software is supplied with the Enterprise Server standalone distribution of Sun GlassFish Enterprise Server. For information about available distributions of Sun GlassFish Enterprise Server, see Distribution Types and Their Components in Sun GlassFish Enterprise Server v2.1.1 Installation Guide. HADB features are available only in the enterprise profile. For information about profiles, see Usage Profiles in Sun GlassFish Enterprise Server v2.1.1 Administration Guide.
You perform an application upgrade that involves a change to the application database schema.
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.
Stop one of the clusters using the Stop Cluster button on the General Information page for the cluster.
Upgrade the component in that cluster.
Start the cluster using the Start Cluster button on the General Information page for the cluster.
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.