1. Installing Oracle Coherence
  2. Upgrading Coherence from Previous Releases

5 Upgrading Coherence from Previous Releases

Coherence applications can be upgraded to new Coherence versions to take advantage of new and improved features. The most common upgrading steps are provided and should be followed as required for your application.

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.

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.1.x

You can migrate Coherence 12.1.x applications to 12.2.1.x.

This sections includes the following topics:

Parent topic: Upgrading Coherence from Previous Releases

Update JVM

The minimum supported JVM version for Coherence has changed. See Runtime Requirements.

Parent topic: Upgrading from Version 12.1.x

Update 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 12.2.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.1.x

Update 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

Update 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

Update 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

Plan 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

Update 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 your extractors to use actual extractors (ReflectionExtractor). For example: 

QueryHelper.createExtractor("key().myKey"); 

should be changed to:

new ReflectionExtractor("getMyKey", null,ReflectionExtractor.KEY);

Parent topic: Upgrading from Version 12.1.x

Updated 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

Update 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

Update 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

Migrate 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

Remove 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

Remove 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

Remove 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

Update 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 12.2.1.x, and you need to refer to 12.2.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 12.2.1.x versions of other JAR files used with HotCache. Those classpaths should refer to the following JAR files from the 12.2.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

Update 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

You can migrate Coherence 3.7.1.x applications to 12.x.

Note:

Perform the tasks as required for your Coherence deployment. However, these tasks should be performed only after considering the upgrade issues for 12.1.x which may supersede these instructions. See Upgrading from Version 12.1.x.

This section includes the following topics:

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.

  1. In an existing WebLogic Server domain:

    • Stop and undeploy the applications that use Coherence*Web.

    • Undeploy the coherence.jar and coherence-web-spi.war files if they are deployed.

  2. Follow the steps to upgrade WebLogic Server and its domains to WebLogic Server 12c (12.2.1.1). See Roadmap for Upgrading Your Application Environment in Upgrading Oracle WebLogic Server.
  3. Modify your applications to remove all references to the coherence.jar file:

    • In the weblogic.xml file, remove the <library-ref> element that refers to the coherence-web-spi file.

    • In the META-INF/MANIFEST.MF file, remove the following lines that identify Coherence as an extension: 

      Extension-List: coherence
coherence-Extension-Name: coherence

    • Remove any explicit references to the coherence.jar file in the classpath.

  4. Modify your applications to use the required settings for Coherence 12c (12.2.1.1):

    • If you used the default session-cache-config.xml file in your Coherence release 3.7.1.x application, note that the name has been changed to default-session-cache-config.xml in 12c (12.2.1.1).

      For example, if you used this context parameter value in Coherence release 3.7.1.x application: 

      coherence.cacheconfig=session-cache-config.xml

      change it to default-session-cache-config.xml: 

      coherence.cacheconfig=default-session-cache-config.xml

      You should not have to change the session cache file name. If you created a custom session-cache-config.xml, you should be able to leave the file name as it is.

    • If your application is in an EAR file, then the packaging for the custom session-cache-config file has changed. See Using a Custom Session Cache Configuration File in Administering HTTP Session Management with Oracle Coherence*Web.

  5. Redeploy your applications on WebLogic Server.

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.

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 12c (12.2.1.1), 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 and active-cache.jar files in the system classpath. The active-cache.jar file uses the classpath in the MANIFEST 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 the coherence.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 of coherence.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 and active-cache.jar should not be deployed as shared libraries nor should they appear in the MANIFEST 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.

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 12c (12.2.1.1), the API will now take care of sizing. To upgrade, remove the elements from any configuration files.

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.

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).

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>

Other Upgrade Issues

The following sections describe issues that you might need to consider when upgrading to Coherence 12c (12.2.1.1).

Parent topic: Upgrading from Version 3.7.1.x

New DistributedCache Default for Exalogic Environments

All DistributedCache instances now default to the Infiniband Message Bus (IMB) transport in Exalogic environments. The transport is configured within the <reliable-transport> service parameter. See DistributedCache Service Parameters in Developing Applications with Oracle Coherence.

Parent topic: Other Upgrade Issues

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 12.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 12.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:

Table 5-1 Selecting Coherence and GoldenGate versions for Upgrade

HotCache Coherence Cluster Member Version Minimum JDK Version Minimum OGG/OGGBD VersionFoot 1
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.handler.hotcache.type=oracle.toplink.goldengate.CoherenceAdapter1220
gg.classpath

Note: You can find any non-Coherence jars mentioned below from the Coherence installation under ORACLE_HOME/oracle_common/modules.

For all releases, add the following items to gg.classpath:

  • coherence.jar
  • coherence-hotcache.jar
  • oracle.toplink/eclipselink.jar
  • oracle.toplink/toplink-grid.jar
  • Application domain classes
  • Various XML configuration files

For 12.2.1.4.0, you must also add:

  • javax.persistence.jar

Parent topic: Upgrading Coherence from Previous Releases