5 Upgrading Coherence from Previous Releases
This chapter includes the following sections:
- General Upgrade Guidelines
Understanding and following some basic guidelines before you upgrade to a new Coherence release can ensure a successful upgrade. - Upgrading from Version 12.2.1.x
You can migrate Coherence 12.2.1.x applications to 14c (14.1.1.0).x. - Upgrading from Version 12.1.x
You can migrate Coherence 12.1.x applications to 14c (14.1.1.0).x. - Upgrading from Version 3.7.1.x
You can migrate Coherence 3.7.1.x applications to 14c (14.1.1.0).x. - Upgrading from Coherence HotCache 12.2.1.x to Later Versions
When you upgrade from various Oracle Coherence GoldenGate HotCache versions, you must take the following considerations into account.
General Upgrade Guidelines
Understanding and following some basic guidelines before you upgrade to a new Coherence release can ensure a successful upgrade.
General Instructions:
-
Read the Release Notes carefully for any changes to features you may be using.
-
Pay particular attention to changes in default behavior.
-
Plan a period of QA and Performance testing as subtle changes may impact customer SLA.
-
Plan for upgrades to the JVM, if required by the Coherence upgrade.
-
Check compatibilities with any external systems.
-
Do not combine changes in environment, network, external systems with the planned upgrade (or treat it as a new product release).
Parent topic: Upgrading Coherence from Previous Releases
Upgrading from Version 12.2.1.x
You can migrate Coherence 12.2.1.x applications to 14c (14.1.1.0).x.
This section includes the following topics:
Parent topic: Upgrading Coherence from Previous Releases
Updating JVM
The minimum supported JVM version for Coherence has changed. See Runtime Requirements.
Parent topic: Upgrading from Version 12.2.1.x
Update Maven Build Scripts
The version is now 14.1.1-0-0. If you are using Maven to create, build, and deploy Oracle Coherence applications, then you must change your scripts accordingly. See Building Oracle Coherence Projects with Maven in Developing Applications Using Continuous Integration.
Parent topic: Upgrading from Version 12.2.1.x
Perform a Rolling Restart
Install Oracle Coherence 14.1.1.0 to a new Oracle Home and copy the application files to the new Oracle Home. Then, start the new 14.1.1.0 Coherence servers and bring down Coherence 12.2.1.x servers in a rolling fashion. See Performing a Rolling Restart in Developing Applications with Oracle Coherence for details on how to perform a rolling restart of a Coherence cluster without losing cache data
Parent topic: Upgrading from Version 12.2.1.x
Upgrading from Version 12.1.x
You can migrate Coherence 12.1.x applications to 14c (14.1.1.0).x.
This section includes the following topics:
- Updating JVM
- Updating Maven Build Scripts
- Updating Cache Configuration File
- Updating Address and Port Assignments
- Updating Multiple Clusters that Run on the Same Network
- Planning for TCP Usage
- Updating Extractor Implementations
- Updating Packaging for Coherence REST on WebLogic Server
- Running coherence.jar for the Coherence Console
- Updating CohQL Scripts
- Updating the Coherence*Web Configuration
- Migrating to a Supported Web Container
- Removing ActiveCache Integrations
- Removing Encryption Filters
- Removing TopLink Grid Implementations
- Updating Classpaths for HotCache
- Updating Custom Health Monitors
Parent topic: Upgrading Coherence from Previous Releases
Updating JVM
The minimum supported JVM version for Coherence has changed. See Runtime Requirements.
Parent topic: Upgrading from Version 12.1.x
Updating Maven Build Scripts
The maven-gar-plugin
plug-in and
maven-gar-archetype
archetype have been refactored to
gar-maven-plugin
and gar-maven-archetype
,
respectively. Also, the version is now 14.1.1-2206-1. If you are using Maven to create,
build, and deploy Oracle Coherence applications, then you must change your scripts
accordingly. See Building Oracle Coherence Projects with Maven in Developing Applications Using Continuous Integration.
Parent topic: Upgrading from Version 12.1.x
Updating Cache Configuration File
A new default cache configuration file is included in the coherence.jar
library. The new default configuration is not backwards compatible with the previous configuration. If your solution relies on the previous default cache configuration file, then the proper work around is to author a new cache configuration file that defines the required cache mappings and override the default cache configuration file. If your solution does not rely on the default cache configuration file, then no update is required.
Parent topic: Upgrading from Version 12.1.x
Updating Address and Port Assignments
Significant enhancements have been made to simplify the way Coherence addresses and ports are configured and may require updates to your solution. The enhancements include:
-
Coherence now uses port 7574 as the default cluster port for multicast communication and
239.192.0.0
as the default address. Addresses and ports that are explicitly configured are still used. However, solutions that rely on the previous defaults need to be updated to use the new defaults. See Specifying a Cluster's Multicast Address and Port in Developing Applications with Oracle Coherence. -
Unicast Ports are now automatically selected. Unicast ports that are explicitly configured are still used. However, solutions that relied on the previous default ports need to be updated accordingly. For most use cases, unicast ports do not need to be explicitly configured. See Specifying a Cluster Member Unicast Address and Port in Developing Applications with Oracle Coherence.
-
WKA addresses now use the cluster port. WKA addresses which contain an explicit port are still respected but it is recommended that the new form which does not include a port be used instead as it provides increased availability. However, solutions that relied on the previous default port need to be updated accordingly. See Specifying WKA Addresses in Developing Applications with Oracle Coherence.
-
The Name service now automatically uses the cluster port. Proxy addresses that are explicitly configured are still used. However, extend clients that rely on the Name service to find a proxy and rely on the previous default Name service port must be updated to use the new default. Extend clients that run on the same network as the proxy and use the Name service are no longer required to configure an address or a port, so long as they have an operational configuration which is compatible with the cluster. See Defining a Single Proxy Service Instance in Developing Remote Clients for Oracle Coherence.
Parent topic: Upgrading from Version 12.1.x
Updating Multiple Clusters that Run on the Same Network
Multiple clusters can now share a cluster port and Multicast or WKA address. For most use cases, there is no reason to change the cluster port, or multicast address. Note that clusters configured to use SSL do not support sharing. In addition, clusters that are configured to only support IPv4 (-DpreferIPv4Stack=true
) can only share with other clusters that are configured to only support IPv4. the use of -DpreferIPv4Stack=true
is generally not necessary. If your solution includes multiple clusters on the same network, consider using the Coherence defaults addresses and port and not explicitly configuring addresses and ports. Note that when using shared addresses and ports the selection of a unique cluster name is required.
Parent topic: Upgrading from Version 12.1.x
Planning for TCP Usage
The default protocol that is used between clustered data services has changed from UDP to TCP message bus (TMB). UDP is still used for cluster maintenance while TCP is used for workloads which may be more performance sensitive. Most networks are already optimally configured for TCP and do not require Coherence-specific configuration. In addition, there should be very little network load difference between UDP and TCP. A message bus test utility is provided that can be used test TMB performance between network nodes. See Running the Message Bus Test Utility and TCP Considerations in Administering Oracle Coherence.
Solutions that require the use of a firewall between cluster members should ensure that the cluster port (7574) is open for both UDP and TCP for both multicast and unicast configurations as well as port 7 for Coherence TcpRing/IpMonitor death detection. Lastly, ensure that the unicast port range is open for both UDP and TCP traffic and that the unicast listen port range is explicitly set rather then relying upon a system assigned ephemeral port. See Changing the Default Unicast Port in Developing Applications with Oracle Coherence.
Parent topic: Upgrading from Version 12.1.x
Updating Extractor Implementations
The QueryHelper.createExtractor()
API does not produce value
extractors that are equivalent with previous versions of Coherence. Do not use
QueryHelper.createExtractor()
for indexes and extend client filters
if you have extend clients running previous versions of Coherence. Instead, you should
change the extractors to use the actual extractors
(ReflectionExtractor
).
For example, change
QueryHelper.createExtractor("key().myKey");
to new
ReflectionExtractor("getMyKey", null,ReflectionExtractor.KEY);
Parent topic: Upgrading from Version 12.1.x
Updating Packaging for Coherence REST on WebLogic Server
WebLogic Server now includes the coherence-rest.jar
library in the server classpath. Existing Coherence REST applications that are deployed on WebLogic server should be repackaged and the coherence-rest.jar
library should be removed from the application. See Deploying to WebLogic Server in Developing Applications with Oracle Coherence.
Parent topic: Upgrading from Version 12.1.x
Running coherence.jar for the Coherence Console
Executing java -jar coherence.jar
starts a DefaultCacheServer
instance rather than the legacy Coherence console. If your solution depends on the console, you can start the console using the bin/coherence
script or directly using:
java -cp coherence.jar com.tangosol.net.CacheFactory
Parent topic: Upgrading from Version 12.1.x
Updating CohQL Scripts
The BACKUP
CACHE
and RESTORE CACHE
statements available in CohQL are deprecated. Applications or scripts that relied on these commands must be updated to use Coherence persistence and the new persistence statements. See Persisting Cache Data to Disk in Developing Applications with Oracle Coherence.
Parent topic: Upgrading from Version 12.1.x
Updating the Coherence*Web Configuration
The default Coherence*Web session configuration file no longer includes a near cache definition. Applications that were dependent on the near cache configuration must override the default configuration file and define a near cache definition. See Defining Near Cache Schemes in Developing Applications with Oracle Coherence.
Parent topic: Upgrading from Version 12.1.x
Migrating to a Supported Web Container
Coherence*Web no longer supports the following web containers: Apache Tomcat 5.5.n, Apache Tomcat 6.0.n, Caucho Resin 3.1.n, IBM WebSphere 5.n, IBM WebSphere 6.n, IBM WebSphere 7.n, Sun GlassFish 2.n, Sun Application Server 8.n, Oracle OC4J 10.1.3.n, Oracle OC4J 10.1.2.n, Oracle GlassFish 3.n, Oracle GlassFish 4.n, Jetty 6.1.n, Jetty 5.1.n, JBoss Application Server. Applications that require Coherence HTTP session management must be migrated to use a supported web container version. See Supported Web Containers in Administering HTTP Session Management with Oracle Coherence*Web.
Parent topic: Upgrading from Version 12.1.x
Removing ActiveCache Integrations
The active-cache.jar
library that was previously used to integrate Coherence with WebLogic Server has been removed from the WLS distribution. Solutions that rely on the Coherence and WLS integration must be re-factored to use the Managed Coherence Server integration instead. See Deploying Coherence Applications to WebLogic Server in Administering Oracle Coherence.
Parent topic: Upgrading from Version 12.1.x
Removing Encryption Filters
Encryption filters are no longer available and can no longer be used. Solutions that rely on encryption filters must now be configured to use SSL. See Using SSL to Secure Communication in Securing Oracle Coherence.
Parent topic: Upgrading from Version 12.1.x
Removing TopLink Grid Implementations
TopLink Grid has been deprecated in the TopLink product. Applications must be re-architected to use the Coherence API in their data access layers instead of using the JPA API.
Parent topic: Upgrading from Version 12.1.x
Updating Classpaths for HotCache
Applications that use Oracle Coherence GoldenGate HotCache require an additional JAR file to certain JVM classpaths when upgrading from Coherence version 12.1.x to 14.1.1.x, and you need to refer to 14.1.1.x distributions of other JAR files in those same JVM classpaths.
Specifically, all cache server JVMs (storage-enabled cluster members) need to include
ORACLE_HOME/coherence/lib/coherence-hotcache.jar
on their
classpaths. Likewise, all HotCache JVMs need to include that same JAR file on their
classpaths. The classpaths of HotCache JVMs are configured in a properties file. See
Configuring HotCache in Integrating Oracle Coherence. Classpaths of cache server and HotCache JVMs also
need to be modified to refer to 14.1.1.x versions of other JAR files used with
HotCache. Those classpaths should refer to the following JAR files from the
14.1.1.x installation and not older versions of the same JAR files from a
12.1.x installation:
-
ORACLE_HOME/coherence/lib/coherence.jar
-
ORACLE_HOME/oracle_common/modules/javax.persistence.jar
-
ORACLE_HOME/oracle_common/modules/oracle.toplink/eclipselink.jar
-
ORACLE_HOME/oracle_common/modules/oracle.toplink/toplink-grid.jar
Parent topic: Upgrading from Version 12.1.x
Updating Custom Health Monitors
The hexadecimal receive string that is required to ping Coherence from a BIG-IP LTM custom health monitor has changed. If your solution makes use of a BIG-IP LTM custom health monitor to ping Coherence, then you must update the monitor to use the new hexadecimal string. See Using Advanced Health Monitoring in Developing Remote Clients for Oracle Coherence.
Parent topic: Upgrading from Version 12.1.x
Upgrading from Version 3.7.1.x
Note:
Perform the tasks as required for your Coherence deployment. However, these tasks should be performed only after considering the upgrade issues for 14c (14.1.1.0).x which may supersede these instructions. See Upgrading from Version 12.1.x.This section includes the following topics:
- Upgrading Applications Using Coherence and Coherence*Web on WebLogic Server
- Upgrading Coherence*Extend
- Upgrading Coherence*Web
- Upgrading ActiveCache Applications on WebLogic Server
- Replacements for Deprecated Features
- Other Upgrade Issues
Parent topic: Upgrading Coherence from Previous Releases
Upgrading Applications Using Coherence and Coherence*Web on WebLogic Server
Follow these instructions for upgrading applications running on WebLogic Server that use Coherence and Coherence*Web.
Parent topic: Upgrading from Version 3.7.1.x
Upgrading Coherence*Extend
For all Extend client customers (Java, C++, and .NET), you must upgrade the cluster side before upgrading the Coherence*Extend clients. This is in compliance with the Coherence client and proxy upgrade policy. See Compatibility Between Coherence*Extend Versions in Installing Oracle Coherence.
Parent topic: Upgrading from Version 3.7.1.x
Upgrading Coherence*Web
The following sections describe upgrade considerations for Coherence*Web.
- Coherence*Web SPI Reserved for Older Versions of WebLogic
- ActiveCache (active-cache.jar) Replaced with Managed Coherence Servers
- New Session Cache Configuration File
Parent topic: Upgrading from Version 3.7.1.x
Coherence*Web SPI Reserved for Older Versions of WebLogic
The coherence-web-spi.war
file, which was included in previous
releases of Coherence*Web, is deprecated. If you are using WebLogic Server 14c
(14.1.1.0), you should not have to work with or reference this file. If you attempt to
deploy the coherence-web-spi.war
file to WebLogic Server 12c
(12.2.1.1), it will be ignored.
Parent topic: Upgrading Coherence*Web
ActiveCache (active-cache.jar) Replaced with Managed Coherence Servers
ActiveCache (active-cache.jar
), the collection of WebLogic Server features which allow deployed applications to easily use Coherence data caches and seamlessly incorporate Coherence*Web for session management, has been deprecated since the 12.1.2. release.
Users must migrate to Managed Coherence Servers when developing new WebLogic Server/Coherence applications for the current release. See Deploying Coherence Applications to WebLogic Server in Administering Oracle Coherence.
Parent topic: Upgrading Coherence*Web
New Session Cache Configuration File
In previous releases, Coherence cache configurations and services used by Coherence*Web SPI were defined in the session-cache-config.xml
file, As of the 12c (12.2.1.1), Coherence cache configurations and services used by Coherence*Web are defined in the default-session-cache-config.xml
file, which can be found in the coherence-web.jar
file. The default cache and services configuration defined in the default-session-cache-config.xml
file should satisfy most Web applications.
You can create your own custom session cache configuration by packaging a file named session-cache-config.xml
in your Web application. See Using a Custom Session Cache Configuration File in Administering HTTP Session Management with Oracle Coherence*Web.
Parent topic: Upgrading Coherence*Web
Upgrading ActiveCache Applications on WebLogic Server
The 11g Release 1 (10.3.6) version of ActiveCache is documented in About ActiveCache in Oracle Fusion Middleware Using ActiveCache. This version of ActiveCache will work with WebLogic Server and Coherence 12.1.2 but some of the documented steps are no longer required.
Note:
ActiveCache has been deprecated since the 12.1.2 release. Users must migrate to Managed Coherence Servers. See Deploying Coherence Applications to WebLogic Server in Administering Oracle Coherence.
-
Choose the ActiveCache Deployment Topology in Oracle Fusion Middleware Using ActiveCache describes the several different combinations of application and data tiers, or cluster topologies, in which ActiveCache can be deployed. In upgrading applications using ActiveCache, you should not use the Out-of-Process topology except for backward compatibility. In the current release, WebLogic Out-of-Process topology is the preferred approach. Using managed Coherence servers makes the WebLogic Out-of-Process topology easier to configure.
-
Locate the Cache Configuration File in Oracle Fusion Middleware Using ActiveCache describes the location where you place the cache configuration file. The location where you store the cache configuration file determines the cache scope; that is, the visibility of the caches to deployed applications. The approaches described in this section will work, but putting the cache configuration in the system classpath is a bad practice unless there is only one and will only ever be one application using Coherence in the server.
Oracle recommends that you use a GAR file when you package your application. The cache configuration file is packaged in the GAR file. For more information on the GAR file and its packaging structure, see Packaging Coherence Applications in Developing Oracle Coherence Applications for Oracle WebLogic Server.
-
Configuring Application-Server Scoped Coherence Clusters in Oracle Fusion Middleware Using ActiveCache describes a configuration such that all deployed applications on WebLogic Server instances that are directly accessing Coherence caches become part of one Coherence cluster. In the procedure, do not perform Step 1: do not put the
coherence.jar
andactive-cache.jar
files in the system classpath. Theactive-cache.jar
file uses the classpath in theMANIFEST
file to add the Coherence integration module to the classpath. In release 12.1.2, the Coherence integration module will always be in the server classpath, in addition to thecoherence.jar
file. -
Configuring EAR-Scoped Coherence Clusters in Oracle Fusion Middleware Using ActiveCache describes a configuration such that all deployed applications within each EAR become part of one Coherence cluster. Caches will be visible to all modules in the EAR. The procedure described in this section will not work as described. Because
coherence.jar
is already in the system classpath, you must follow the steps documented in the for using a filtering Classloader.The only reason to use the EAR-scoped approach is to isolate your application from other Coherence applications. That use case is better handled by the application isolation provided by a GAR file, or by using the
scope
element in the cache configuration file. Another use case is to use a different version ofcoherence.jar
than is in the system classpath but using a different version should be discouraged. -
Configuring WAR-Scoped Clusters in Oracle Fusion Middleware Using ActiveCache describes a configuration such that each deployed Web application becomes its own Coherence cluster. Caches will be visible to the individual modules only. In the procedure, do not perform Steps 1 and 2. The
coherence.jar
andactive-cache.jar
should not be deployed as shared libraries nor should they appear in theMANIFEST
file. You can perform Step 3 to reference the Coherence cluster system resource, but making the managed server a member of the Coherence cluster is the preferred approach. -
Example 3-10 tangosol-coherence-override.xml in Oracle Fusion Middleware Using ActiveCache displays a custom cache configuration file that contains a logging configuration. The logging configuration is not required.
-
Start a Cache Server in Oracle Fusion Middleware Using ActiveCache describes several different ways of starting the cache server. The Out-of-Process topology should be replaced with managed Coherence servers. The procedure for starting a cache server using node manager should be performed by using managed Coherence servers, instead of using the external cache server managed by WebLogic Server.
Parent topic: Upgrading from Version 3.7.1.x
Replacements for Deprecated Features
The following sections describe replacements for features that have been deprecated since Coherence 12.1.2.
- Replacement for Deprecated packet-pool and message-pool Elements
- Replacement for the Deprecated LH File Manager
- Replacement for the Deprecated NamedCache Lock APIs
- Replacement for the Deprecated XmlConfigurable Interface
Parent topic: Upgrading from Version 3.7.1.x
Replacement for Deprecated packet-pool and message-pool Elements
The packet-pool
and message-pool
elements are
deprecated. In Coherence 14.1.1.0.x, the API will now take care of sizing. To
upgrade, remove the elements from any configuration files.
Parent topic: Replacements for Deprecated Features
Replacement for the Deprecated LH File Manager
The LH store manager is deprecated as of Coherence 12.1.2 release. Use Berkeley DB for similar functionality.
Parent topic: Replacements for Deprecated Features
Replacement for the Deprecated NamedCache Lock APIs
The NamedCache
lock
APIs are deprecated. Use the locking support that is provided by the entry processor API instead (EntryProcessor
for Java and C++, IEntryProcessor
for .NET).
Parent topic: Replacements for Deprecated Features
Replacement for the Deprecated XmlConfigurable Interface
The com.tangosol.run.xml.XmlConfigurable
interface has been deprecated since the Coherence 12.1.2 release. Coherence used this interface to inject XML parameters into instances of custom classes.
In the Coherence 12c (12.2.1.1) release, you can initialize parameters by writing XML which nests <instance>
and <class-scheme>
(or any other custom namespace) inside of <param-value>
elements.
For example, given the following Java code:
public class MyClass { public MyClass(String s, OtherClass o, int i) { ... } } public class OtherClass { public OtherClass(String s) { ... } }
You can initialize the MyClass
and OtherClass
classes by writing the following XML. In the XML, the MyClass
class is initialized with the string Hello
World
and the integer 42
. The instance of the OtherClass
class which appears in the MyClass
class, is initialized with the string Goodbye
World
.
<instance> <class-name>MyClass</class-name> <init-params> <init-param> <param-value>Hello World</param-value> </init-param> <init-param> <param-value> <instance> <class-name>OtherClass</class-name> <init-params> <init-param> <param-value>Goodbye World</param-value> </init-param> </init-params> </instance> </param-value> </init-param> <init-param> <param-value>42</param-value> </init-param> </init-params> </instance>
Parent topic: Replacements for Deprecated Features
Other Upgrade Issues
The following sections describe issues that you might need to consider when upgrading to Coherence 14c (14.1.1.0).x.
- Connecting from Remote RMI Clients
- Key Associations on the Coherence*Extend Client
- Changes to Invalidation Strategy for Near Caches
- New Cache Configuration Element: resource-config
- Changes to Invocable API Behavior
Parent topic: Upgrading from Version 3.7.1.x
Connecting from Remote RMI Clients
When connecting from a remote RMI client (different physical computer), add the java.rmi.server.hostname
RMI system property to the script with the value set to the cluster member's IP address. The address ensures that the RMI stubs that are sent to the client contain the correct server address. See Allowing Remote Access to Oracle Coherence MBeans in Managing Oracle Coherence.
Parent topic: Other Upgrade Issues
Key Associations on the Coherence*Extend Client
Key association is now processed on the extend client by default. Existing client implementations (including Java clients) that rely on key association on the cluster must set the defer-key-association-check
parameter in order to force the processing of key classes on the cluster.
To force key association processing to be done on the cluster side instead of by the extend client, set the <defer-key-association-check>
element, within a <remote-cache-scheme>
element, in the client-side cache configuration to true. For example:
<remote-cache-scheme> ... <defer-key-association-check>true</defer-key-association-check> </remote-cache-scheme>
See Deferring the Key Association Check in Developing Remote Clients for Oracle Coherence.
Parent topic: Other Upgrade Issues
Changes to Invalidation Strategy for Near Caches
The default near cache invalidation strategy auto
has changed to ensure that reduced network traffic is prioritized over performance. Set the invalidation strategy to all
for pre-12c (12.2.1.1) default behavior. See Near Cache Invalidation Strategies in Developing Applications with Oracle Coherence.
Parent topic: Other Upgrade Issues
New Cache Configuration Element: resource-config
The resource-config
element contains the configuration information for a class that extends the com.sun.jersey.api.core.ResourceConfig
class. The instance is used by the HTTP acceptor to load resource and provider classes for the Coherence REST application that is mapped to the specified context path. Multiple resource configuration classes can be configured and mapped to different context paths. See Deploying with the Embedded HTTP Server in Developing Remote Clients for Oracle Coherence.
Parent topic: Other Upgrade Issues
Changes to Invocable API Behavior
Applications that use the Invocable API may receive an error when upgrading from Coherence 3.7.1 to Coherence 14.1.1.0.x due to a change in serialization requirements. In Coherence 3.7.1, if an Invocable is sent to a number of nodes including itself, then there is a chance that it will begin local execution before having been serialized for transmission to the remote members. If the Invocable updates non-transient state, this state will be leaked to the other nodes as part of the delayed serialization.
In Coherence 14.1.1.0.x, applications that use the Invocable API on local members must make sure that their classes (such as entry processors and aggregators) are serializable.
Parent topic: Other Upgrade Issues
Upgrading from Coherence HotCache 12.2.1.x to Later Versions
When you upgrade from various Oracle Coherence GoldenGate HotCache versions, you must take the following considerations into account.
For information on how Oracle Coherence and HotCache work together, see Integrating with Oracle Coherence GoldenGate HotCache in Integrating Oracle Coherence.
Prerequisites for Oracle GoldenGate and GoldenGate Big Data
For more information on installing or upgrading Oracle GoldenGate (OGG) and Oracle GoldenGate Big Data (OGGBD), see:
- Installing Oracle GoldenGate Classic Architecture 21c
- Upgrading Oracle GoldenGate Classic in Upgrading Oracle GoldenGate 21c
- Installing Oracle GoldenGate Classic for Big Data in Installing and Upgrading Oracle GoldenGate for Big Data 21c
- Upgrading Oracle GoldenGate Classic for Big Data in Installing and Upgrading Oracle GoldenGate for Big Data 21c
Table 5-1 Selecting Coherence and GoldenGate versions for Upgrade
HotCache Coherence Cluster Member Version | Minimum JDK Version | Minimum OGG/OGGBD VersionFoot 1 |
---|---|---|
14.1.1.x, 12.2.1.4.x | 8 | 19.1.0.0.4.002 |
Footnote 1 Oracle recommends using the latest available patch.
While it is recommended to use a HotCache Coherence cluster member, if it is not possible to run with the minimum OGG/OGGBD version supported by targeted upgrade Coherence version, then running with a HotCache Coherence extend client allows running with OGG/OGGBD version lower than minimum versions listed in table above. For information about running as a HotCache extend client, see Provide Coherence*Extend Connection Information in Integrating Oracle Coherence.
Updates to srccapt.prm
The RecoveryOptions OverwriteMode
command is now obsolete and should be removed from srccapt.prm
.
Updates to the HotCache Properties File
You must update the .properties
file that contains the configuration for HotCache.
Table 5-2 contains descriptions of the changes you must make when moving between HotCache releases. For descriptions of all required properties, see Create a Properties File with GoldenGate for Java Properties in Integrating Oracle Coherence. Make sure you refer to the correct version of the documentation for your target upgrade.
Table 5-2 Summary of Changes to the HotCache Properties File
Property | Required Changes |
---|---|
gg.handler.hotcache.type |
For Oracle GoldenGate Application Adapters 12.2.0 or later, set |
gg.classpath |
Note: You can find any non-Coherence jars mentioned below from the Coherence installation under For all releases, add the following items to
For 14.1.1.0.0, you must also add:
For 12.2.1.4.0, you must also add:
|
Parent topic: Upgrading Coherence from Previous Releases