JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide
search filter icon
search icon

Document Information


1.  High Availability in GlassFish Server

2.  Setting Up SSH for Centralized Administration

3.  Administering GlassFish Server Nodes

4.  Administering GlassFish Server Clusters

5.  Administering GlassFish Server Instances

6.  Administering Named Configurations

7.  Configuring Web Servers for HTTP Load Balancing

8.  Configuring HTTP Load Balancing

9.  Upgrading Applications Without Loss of Availability

Application Compatibility

Upgrading In a Single Cluster

To Upgrade an Application in a Single Cluster

Upgrading in Multiple Clusters

To Upgrade a Compatible Application in Two or More Clusters

Upgrading Incompatible Applications

To Upgrade an Incompatible Application by Creating a Second Cluster

10.  Configuring High Availability Session Persistence and Failover

11.  Configuring Java Message Service High Availability

12.  RMI-IIOP Load Balancing and Failover


Chapter 9

Upgrading Applications Without Loss of Availability

Upgrading an application to a new version without loss of availability to users is called a rolling upgrade. Carefully managing the two versions of the application across the upgrade ensures that current users of the application complete their tasks without interruption, while new users transparently get the new version of the application. With a rolling upgrade, users are unaware that the upgrade occurs.

For more information about application versions and how they are identified, see Module and Application Versions in Oracle GlassFish Server 3.1 Application Deployment Guide.

In a clustered environment, a rolling upgrade redeploys an application with a minimal loss of service and sessions. A session is any artifact that can be replicated, for example:

A rolling upgrade can take place under light to moderate loads. The procedure requires about 10-15 minutes for each GlassFish Server instance.


Caution - To prevent the risk of version mismatch when a session fails over, upgrade all instances in a cluster at the same time. Otherwise a session might fail over to an instance where different versions of components are running.

Perform this task on each cluster separately. A cluster acts as a safe boundary for session failover for instances in the cluster. Sessions in one cluster can never fail over to sessions in another cluster. Therefore, the risk of version mismatch is avoided.