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

Upgrading from Version 14.1.1.0.x

Note:

The two patch series 14.1.1.0.x and 14.1.1.2206.x are not compatible and cannot co-exist in the same Oracle Home.
You can migrate Coherence 14.1.1.0.x to 14.1.1.2206.x.

ACTION REQUIRED: When running in Production mode, one must plan for the default lambda serialization mode being changed to static.

This section includes the following topics:

Updating JVM

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

Updating Maven Build Scripts

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.

Rolling Back Any Applied Coherence Patches

For either standalone or WebLogic Server installs, you must roll back all applied Coherence patches in the reverse order you have applied them.

Note:

If this is a fresh install of Coherence or WebLogic Server, skip this step.

For example, if you first applied patches 14.1.1.0.3 and then 14.1.1.0.9, you must uninstall patch 14.1.1.0.9 and then 14.1.1.0.3. You can use opatch lsinventory to view the applied Coherence patches and roll them back until you are back to 14.1.1.0.0.

Create a script (similar to the scripts shown below) that contains the following commands to remove all Coherence patches that have been applied to the Oracle Home. If a particular patch is not applied, ignore the Patch not present in the Oracle Home message; the script continues to the next patch.

Note:

Review the release notes for the complete list of patch IDs that you should roll back.
For Linux/ Mac
OPatch/opatch rollback -id 34248968 -silent -jdk $JAVA_HOME # 14.1.1.0.10
OPatch/opatch rollback -id 33902209 -silent -jdk $JAVA_HOME # 14.1.1.0.9
OPatch/opatch rollback -id 33591037 -silent -jdk $JAVA_HOME # 14.1.1.0.8
OPatch/opatch rollback -id 33286174 -silent -jdk $JAVA_HOME # 14.1.1.0.7
OPatch/opatch rollback -id 32973306 -silent -jdk $JAVA_HOME # 14.1.1.0.6
OPatch/opatch rollback -id 32816973 -silent -jdk $JAVA_HOME # 14.1.1.0.5
OPatch/opatch rollback -id 32581868 -silent -jdk $JAVA_HOME # 14.1.1.0.4
OPatch/opatch rollback -id 32124447 -silent -jdk $JAVA_HOME # 14.1.1.0.3
OPatch/opatch rollback -id 31806281 -silent -jdk $JAVA_HOME # 14.1.1.0.2
OPatch/opatch rollback -id 31201347 -silent -jdk $JAVA_HOME # 14.1.1.0.1
For Windows
OPatch\opatch rollback -id 34248968 -silent -jdk %JAVA_HOME% & REM 14.1.1.0.10
OPatch\opatch rollback -id 33902209 -silent -jdk %JAVA_HOME% & REM 14.1.1.0.9
OPatch\opatch rollback -id 33591037 -silent -jdk %JAVA_HOME% & REM 14.1.1.0.8
OPatch\opatch rollback -id 33286174 -silent -jdk %JAVA_HOME% & REM 14.1.1.0.7
OPatch\opatch rollback -id 32973306 -silent -jdk %JAVA_HOME% & REM 14.1.1.0.6
OPatch\opatch rollback -id 32816973 -silent -jdk %JAVA_HOME% & REM 14.1.1.0.5
OPatch\opatch rollback -id 32581868 -silent -jdk %JAVA_HOME% & REM 14.1.1.0.4
OPatch\opatch rollback -id 32124447 -silent -jdk %JAVA_HOME% & REM 14.1.1.0.3
OPatch\opatch rollback -id 31806281 -silent -jdk %JAVA_HOME% & REM 14.1.1.0.2
OPatch\opatch rollback -id 31201347 -silent -jdk %JAVA_HOME% & REM 14.1.1.0.1
After you have removed all the Coherence patches, verify the Coherence version by using the following command to start a console without creating a cluster.
java -cp coherence/lib/coherence.jar com.tangosol.net.CacheFactory @

This command shows the Coherence version for 14.1.1.0.0. Use CTRL-C to exit the console.

Applying WebLogic Server CPU/PSU Patches

If you are patching a WebLogic Server instance or doing a fresh install, you should apply the latest WebLogic Server Critical Patch Update (CPU) or Patch Set Update (PSU) patches.

Note:

Do not apply any Stack Patch Bundles (SPB) as these will apply the most recent 14.1.1.0.x patch.

Applying the 14.1.1.2206 Feature Pack Patch

Download the 14.1.1.2206.1 patch 34372869 from Oracle, and then follow the OPatch instructions to apply this patch to the 14.1.1.0.0 Oracle Home. For OPatch instructions, see Patching Your Environment Using OPatch. Verify that the Coherence version is 14.1.1.2206.1 by using the following command:
java -jar coherence/lib/coherence.jar --version

Recompiling Your Application

You must recompile your application code against the newly patched Coherence version and a supported Java 11 JDK/JRE.

Planning for the Default Lambda Serialization Mode Being Changed to Static

Dynamic lambdas present a security vulnerability due to reliance on remote code deployment across the distributed environment. Accordingly, the default for lambdas serialization mode for Coherence production mode is changed to static as of Coherence release 14.1.1.2206.x. Upgrading a Coherence environment running in production mode to Coherence 14.1.1.2206.x requires planning on whether the required distributed environment changes, that is, updating classpath/modulepath for extend clients/cluster members, are going to be made to enable static lambda serialization mode to work or whether to explicitly enable dynamic lambda serialization mode. To assist your evaluation of which lambda serialization mode is appropriate for your environment, see About Lambdas in a Distributed Environment in Developing Applications with Oracle Coherence.

The quick start way for evaluating upgrading an existing Coherence distributed environment to Coherence 14.1.1.2206.x is to explicitly configure dynamic lambdas by setting the system property coherence.lambdas=dynamic, for all coherence extend Java clients and Coherence cluster members.

Performing a Rolling Restart (Optional)

Oracle recommends a full cluster restart after you apply the 14.1.1.2206 Feature Pack patch. However, it may be possible to carry out a rolling upgrade depending on your environment. This decision will depend upon the use of Coherence features and the complexity of your environment.

For more information about rolling restart, see Performing a Rolling Restart.

Upgrading from Version 12.2.1.x

You can migrate Coherence 12.2.1.x to 14.1.1.2206.x.

This section includes the following topics:

Updating JVM

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

Updating Maven Build Scripts

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.

Performing a Rolling Restart (Optional)

Install Oracle Coherence 14c (14.1.1.0) in a new Oracle Home, and then follow the instructions to apply the 14.1.1.2206 Feature Pack patch. For instructions, see Upgrading from Version 14.1.1.0.x. After you apply the patch, start the new 14.1.1.2206.x Coherence servers and bring down the servers of the previous Coherence version 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.

The actions described in Planning for the Default Lambda Serialization Mode Being Changed to Static apply to performing a rolling upgrade from Coherence 12.2.1.x environment to Coherence 14.1.1.2206.x.

Upgrading from Version 12.1.x

You can migrate Coherence 12.1.x to 14.1.1.2206.x.

This section includes the following topics:

Updating JVM

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

Upgrading from Version 3.7.1.x

You can migrate Coherence 3.7.1.x to 14.1.1.2206.x.

Note:

Perform the tasks as required for your Coherence deployment. However, these tasks should be performed only after considering the upgrade issues for 14.1.1.2206.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

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 14c (14.1.1.0). 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 14.1.1.0.x:
    • If you have used the default session-cache-config.xml file in your Coherence release 3.7.1.x application, note that the name is default-session-cache-config.xml in 14.1.1.0.x.

      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.

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.

Upgrading Coherence*Web

The following sections describe upgrade considerations for Coherence*Web.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.