Mixing WebSphere Application Server versions in the same repository can cause problems

Technote (FAQ)
Problem
When installing a fix pack, or when migrating a version of WebSphereŽ Application Server, it is important to keep all of the nodes in the WebSphere Application Server repository at the same level.
Cause
WebSphere Application Server can, and often does, change the schema of their repository database from version to version, even from fix pack to fix pack. As a result, we do not recommend running WebSphere nodes of different versions in the same repository.

For example, WebSphere Application Server V4.0.2 (Fix Pack 2) introduced a schema change. As a result, when nodes running WebSphere Application Server V4.0.1 and V4.0.2 are in the same repository, the V4.0.1 nodes do not start.
Solution
In cases where the repository is shared by more than one node, the solution involves temporarily, or permanently, configuring multiple WebSphere nodes:

Separate repository configuration:

A suggested best practice is to configure multiple WebSphere Application Server configurations, each with their own repository. This eliminates the repository as a single point of failure, but increases the complexity of administering WebSphere Application Server and deploying applications.

In this scenario, you install WebSphere Application Server into a new directory, following directions for coexistence in the Release Notes.

Notes:

  • Create a new repository on each system when you install.
  • Keep in mind that you will probably want to manually configure the plug-in on your local or remote Web server to perform failover.


Temporarily separate repository:

Temporarily create a second repository, then migrate from the old repository to the new repository, one node at a time.

In this scenario, you create a second repository that uses the new version of code to be installed. Once the repository is created, one node at a time:

  1. Use XMLConfig -export to save the current configuration.
  2. Stop WebSphere Application Server processes.
  3. Change the configuration to point to new repository.
  4. Install the fix pack, following all directions in readme for upgrade.
  5. Start WebSphere Application Server.
  6. Alter XMLConfig's output file to reference and configuration changes (for example, new repository), then perform XMLConfig -import to restore the configuration in the repository.
  7. After the last node is moved to the new repository and verified, delete the old repository.

Notes:
  • WebSphere Application Server V3.5 XMLConfig -export has EJB-specific limitations.
  • When doing a complete reinstall, do not select the option to create a default server, because XMLConfig -import restores the default server that was already configured.


Co-existence
Leave the current multi-node configuration up, while installing a new multi-node configuration on the same systems using directions in the Release Notes for coexistence:
  1. Install new version of WebSphere Application Server to different directory on each node.
  2. Configure it to use different ports, as per the coexistence documentation.
  3. Test using a separate instance of Web server.
  4. When all nodes of the new configuration are working correctly (in test) on the production systems, change the Web server configurations to point to ports for the new configuration.
  5. Shutdown the old configuration.

Notes:
  • This configuration provides the ability to maintain current load and throughput.
  • This configuration provides a failover back to the original configuration using all nodes.
  • This is the most complex form of multi-node migration.











Document Information

Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, System Management/Repository
Operating system(s): AIX, HPUX, Linux, Multi-Platform, Solaris, Windows
Software version: 3.5, 4.0
Software edition: Advanced, Base, Single Server, Standard
Reference #: 1052670
IBM Group: Software Group
Modified date: 2005-01-07