Part VIII Building Upgradable Coherence Applications
Successfully upgrading a Coherence application requires careful consideration that must begin during the initial design of the application. It is too late to think about these considerations after the application is in production and the development team is ready to deploy the next version.
In the simplest upgrade scenario, an application consists of a single Coherence cluster where all of the cluster members are shut down and upgraded together and Coherence features such as persistence and federation are not used. In this scenario, you only need to build and test the application before deploying it to production and you do not need to consider backwards compatibility issues.
More complex upgrade scenarios occur when it is not feasible to shutdown and upgrade all parts of the application simultaneously. The complexity of the upgrade process will also depend upon which Coherence features are being used, whether the application is required to support zero-downtime updates, or if parts of the application need to remain on older versions.
Note:
These considerations also apply if you need to downgrade an application to a previous version. If a serious issue is discovered in an in-production application, the only solution may be to revert the changes and downgrade to an earlier version. It may even require a zero-downtime downgrade.
Upgrade Scenarios
Upgrading an application can range from simple single deployments to significantly more complex scenarios, for example:
- A zero downtime upgrade where the application remains running while parts of it are upgraded.
- An application that uses Coherence persistence and will reload data persisted by the old application.
- An application that uses Coherence federation, and the upgraded cluster will federate data to a cluster running the old version of the application, or the new version will receive federated data from a cluster running the old version.
- The application consists of multiple parts that share a Coherence cluster, and these parts have a different development life cycle and are upgraded at different times. These parts could be deployed as other cluster members, as Coherence Extend clients, or as Coherence gRPC clients. In this case, the application APIs and application data must remain compatible between all the parts.
Note:
Coherence does not support rolling upgrades of cluster members on different major Coherence versions. A major Coherence commercial version is where any of the first four parts of the version number differ. For example, you cannot upgrade from 12.2.1.4.x to 14.1.1.0.x, nor from 14.1.1.0 to 14.1.2.0. You can move between patch numbers, that is, 14.1.2.0.x to another 14.1.2.0.x version.
Upgrades that change the Java major version are also not supported for cluster members because Java does not guarantee serialization compatibility between major releases. For example, you can move from Java 17.1 to 17.2 but not from Java 17 to Java 21.
Part VIII contains the following chapters:
- Upgrade Considerations
Coherence has many features, several of which need to be implemented correctly to ensure an application can be successfully upgraded.