This chapter includes the following sections:
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).
This sections provides tasks that are commonly performed when upgrading from 12.1.x to 12.2.1.x.
This section includes the following topics:
The minimum supported JVM version for Coherence has changed. For details, see "Runtime Requirements."
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. For details on using Maven with Coherence, See Developing Applications Using Continuous Integration.
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.
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.
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.
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" in Administering Oracle Coherence. For details on TCP tuning, see "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. For details about configuring the unicast port, see “Changing the Default Unicast Port” in Developing Applications with Oracle Coherence.
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 Remote Clients for Oracle Coherence.
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
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 Developing Applications with Oracle Coherence.
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. For details on defining a near cache, see "Defining Near Cache Schemes" in Developing Applications with Oracle Coherence.
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 Administering HTTP Session Management with Oracle Coherence*Web.
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 Administering Oracle Coherence.
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 Securing Oracle Coherence.
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.
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 as described in Configuring HotCache). 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
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. For details about configuring health monitors, see "Using Advanced Health Monitoring" in Developing Remote Clients for Oracle Coherence.
This section provides common tasks that are used to migrate Coherence 3.7.1.x applications to 12.x. 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:
Follow these instructions for upgrading applications running on WebLogic Server that use Coherence and Coherence*Web.
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. For more information on compatibility between the current release of Coherence*Extend and earlier versions, see "Compatibility Between Coherence*Extend Versions" in Installing Oracle Coherence.
The following sections describe upgrade considerations for Coherence*Web.
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.
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. For more information on Managed Coherence Servers, see Oracle Fusion Middleware Developing Oracle Coherence Applications for Oracle WebLogic Server.
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. For more information see, "Using a Custom Session Cache Configuration File" in Administering HTTP Session Management with Oracle Coherence*Web.
The 11g Release 1 (10.3.6) version of ActiveCache is documented 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. For more information on Managed Coherence Servers, see Oracle Fusion Middleware Developing Oracle Coherence Applications for Oracle WebLogic Server.
"Choose the ActiveCache Deployment Topology" 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" 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 Oracle Fusion Middleware Developing Oracle Coherence Applications for Oracle WebLogic Server.
"Configuring Application-Server Scoped Coherence Clusters" 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" 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 section "To Define a Filtering Classloader for Application-Scoped Coherence Clusters".
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" 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" displays a custom cache configuration file that contains a logging configuration. The logging configuration is not required.
"Start a Cache Server" section describes several different ways of starting the cache server. The Out-of-Process topology should be replaced with managed Coherence servers. The procedure described in "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.
The following sections describe replacements for features that have been deprecated since Coherence 12.1.2.
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.
The LH store manager is deprecated as of Coherence 12.1.2 release. Use Berkeley DB for similar functionality.
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).
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>
The following sections describe issues that you might need to consider when upgrading to Coherence 12c (12.2.1.1).
DistributedCache now defaults to the Infiniband Message Bus (IMB) transport in Exalogic environments. For more information, see the description of the <reliable-transport> element in "DistributedCache Service Parameters" in Developing Applications with Oracle Coherence.
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. For more information, see "Allowing Remote Access to Oracle Coherence MBeans" in Managing Oracle Coherence.
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>
For more information, see "Deferring the Key Association Check" in Developing Remote Clients for Oracle Coherence.
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. For more information, see "Near Cache Invalidation Strategies" in Developing Applications with Oracle Coherence.
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. For more information, see "Deploying with the Embedded HTTP Server" in Developing Remote Clients for Oracle Coherence.
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.