2 Integrating with Oracle Coherence GoldenGate HotCache
A detailed description of Oracle GoldenGate is beyond the scope of this documentation. If you are new to GoldenGate, install the appropriate Oracle GoldenGate for your database environment. See the GoldenGate documentation library at Oracle GoldenGate for Big Data 21c.
-
Preparing the Database for Oracle GoldenGate in Using Oracle GoldenGate with Oracle Database.
-
Installing Oracle GoldenGate Classic for Big Data in Installing and Upgrading Oracle GoldenGate for Big Data.
-
Oracle GoldenGate Java Delivery in Administering Oracle GoldenGate for Big Data.
-
Configuring Java Delivery documents in the Oracle GoldenGate for Big Data 21c documentation library.
Note:
To use HotCache, you must have licenses for Oracle GoldenGate and Coherence Grid Edition. A HotCache Extend Client can be used with Oracle GoldenGate for Big Data 12c/19c and run with Java 8. For a HotCache client running as a cluster member, the cluster member must run with Java 11. The minimum release of Oracle GoldenGate for Big Data that is certified to run with Java 11 is 21.4.0.0.0. See Release Notes for Oracle GoldenGate for Big Data. Oracle recommends that you use the latest available patch. Examples of configuring Oracle GoldenGate scripts and properties in this chapter refer to Oracle GoldenGate for Oracle Database and Oracle GoldenGate for Big Data 21c.This chapter includes the following sections:
- About Oracle Coherence GoldenGate HotCache
Third-party updates to the database can cause Coherence applications to work with data which could be stale and out-of-date. HotCache solves this problem by monitoring the database and pushing any changes into the Coherence cache. - How Does HotCache Work
Before implementing a HotCache solution, take some time to understand HotCache fundamentals and supported features. - Prerequisites
Ensure that you complete the prerequisites prior to using Oracle Coherence GoldenGate HotCache. - Configuring GoldenGate
Updating a cache from a GoldenGate trail file requires configuring GoldenGate and HotCache. You then enable HotCache by configuring the GoldenGate Java Delivery. - Configuring HotCache
HotCache is configured with system properties, EclipseLink JPA mapping metadata, and a JPApersistence.xml
file. - Configuring the GoldenGate Big Data Java Delivery Adapter
The GoldenGate Java Delivery Adapter provides a way to process GoldenGate data change events in Java by configuring an event handler class. - Configuring the Coherence Cache Servers
You must modify the classpaths of all Coherence cache server JVMs that contain caches that are refreshed by HotCache. - Using Portable Object Format with HotCache
POF serialization can be used with HotCache but requires a small update to the POF configuration file(pof-config.xml)
to allow for HotCache and TopLink Grid framework classes to be registered. - Configuring HotCache JPA Properties
You can customize HotCache using a number of custom JPA properties that can be configured per JPA entity type. - Warming Caches with HotCache
HotCache can be used to warm caches by loading an initial dataset. This approach eliminates the need to write custom cache warming programs because it leverages GoldenGate and HotCache for initial cache warming. - Implementing High Availability for HotCache
As a cache client, HotCache can be configured either as a Coherence cluster member or as a Coherence*Extend client connecting to a Coherence proxy service in the cluster. - Support for Oracle Data Types
HotCache uses EclipseLink as its JPA provider. It is reasonable to expect HotCache to support Oracle-specific data types supported by EclipseLink. - Configuring Multi-Threading in HotCache
HotCache can use multiple threads to apply trail file operations to Coherence caches. Multiple threads can increase the throughput of a HotCache process as compared to using a single thread to apply trail file operations. - Managing HotCache
You can manage HotCache to ensure that cache update operations are performed within acceptable time limits. - Fixing Issues
If you run into issues while using HotCache with Coherence, you may be able to resolve the issue using one of the following options.
About Oracle Coherence GoldenGate HotCache
HotCache can be added to any Coherence application. Standard JPA is used to capture the mappings from database data to Java objects. The configuration can be captured in XML exclusively or in XML with annotations.
The following scenario describes how HotCache could be used to work with the database and with applications that use Coherence caches. Figure 2-1 illustrates the scenario.
-
Start GoldenGate Extract, also referred to as Capture. GoldenGate monitors the transaction log for changes of interest. These changes will be placed into a "trail file". See GoldenGate Extract in the Oracle GoldenGate Microservices Documentation.
-
Start the Coherence cache server and warm the cache, if required.
-
Start HotCache so that it can propagate changes in the trail file into the cache. If changes occur during cache warming, then they will be applied to the cache once HotCache is started so no changes are lost.
-
Start an application client. As part of its operation, assume that the application performs repeated queries on the cache.
-
A third-party application performs a direct database update.
-
GoldenGate detects the database change which is then propagated to the Coherence cache by HotCache.
-
The application client detects the change in cache.
Figure 2-1 How HotCache Propagates Database Changes to the Cache
![Description of Figure 2-1 follows Description of Figure 2-1 follows](img/hotcache_db_changes.png)
Description of "Figure 2-1 How HotCache Propagates Database Changes to the Cache"
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
How Does HotCache Work
This section includes the following topics:
- Overview of How HotCache Works
- How the GoldenGate Java Delivery Adapter Uses JPA Mapping Metadata
- Supported Database Operations
- JPA Relationship Support
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
Overview of How HotCache Works
HotCache processes database change events delivered by GoldenGate and maps those changes onto the affected objects in the Coherence cache. It is able to do this through the use of Java Persistence API (JPA) mapping metadata. JPA is the Java standard for object-relational mapping in Java and it defines a set of annotations (and corresponding XML) that describe how Java objects are mapped to relational tables. As Example 2-1 illustrates, instances of an Employee
class could be mapped to rows in an EMPLOYEE
table with the following annotations.
Example 2-1 Mapping Instances of Employee Class to Rows with Java Code
@Entity @Table(name="EMPLOYEE") Public class Employee { @Id @Column(name="ID") private int id; @Column(name="FIRSTNAME") private String firstName; … }
The @Entity
annotation marks the Employee
class as being persistent and the @Id
annotation identifies the id
field as containing its primary key. In the case of Coherence cached objects, the @Id
field must also contain the value of the key under which the object is cached. The @Table
and @Column
annotations associate the class with a named table and a field with a named column, respectively.
For simplification, JPA assumes a number of default mappings such as table name=class
name
and column
name=field
name
so many mappings need only be specified when the defaults are not correct. In Example 2-1, both the table and field names match the Java names so the @Table
and @Column
can be removed to make the code more compact, as illustrated in Example 2-2.
Example 2-2 Simplified Java Code for Mapping Instances of Employee Class to Rows
@Entity Public class Employee { @Id private int id; private String firstName; … }
Note that the Java code in the previous examples can also be expressed as XML. Example 2-3 illustrates the XML equivalent of the Java code in Example 2-1.
Example 2-3 Mapping Instances of Employee Class to Rows with XML
<entity class="Employee"> <table name="EMPLOYEE"/> <attributes> <id name="id"> <column name="ID"/> </id> <basic name="firstName"/> <column name="FIRSTNAME"/> </basic> ... </attributes> </entity>
Similarly, Example 2-4 illustrates the XML equivalent for the simplified Java code in Example 2-2.
Example 2-4 Simplified XML for Mapping Instances of Employee Class to Rows
<entity class="Employee"> <attributes> <id name="id"/> <basic name="firstName"/> ... </attributes> </entity>
Parent topic: How Does HotCache Work
How the GoldenGate Java Delivery Adapter Uses JPA Mapping Metadata
JPA mapping metadata provides mappings from object to relational; however, it also provides the inverse relational to object mappings which HotCache can use. Given the Employee
example, consider an update to the FIRSTNAME
column of a row in the EMPLOYEE
table. Figure 2-2 illustrates the EMPLOYEE
table before the update, where the first name John is associated with employee ID 1, and the EMPLOYEE
table after the update where first name Bob is associated with employee ID 1.
Figure 2-2 EMPLOYEE Table Before and After an Update
![Description of Figure 2-2 follows Description of Figure 2-2 follows](img/database.gif)
Description of "Figure 2-2 EMPLOYEE Table Before and After an Update"
With GoldenGate monitoring changes to the EMPLOYEE
table and HotCache configured on the appropriate trail file, the adapter processes an event indicating the FIRSTNAME
column of the EMPLOYEE
row with primary key 1
has been changed to Bob
. The adapter will use the JPA mapping metadata to first identify the class associated with the EMPLOYEE
table, Employee
, and then determine the column associated with an Employee
's ID field, ID
. With this information, the adapter can extract the ID column value from the change event and update the firstName
field (associated with the FIRSTNAME
column) of the Employee
cached under the ID
column value.
Parent topic: How Does HotCache Work
Supported Database Operations
Database INSERT
, UPDATE
, and
DELETE
operations are supported by the GoldenGate Java Delivery
Adapter. INSERT
operations into a mapped table result in the addition
of a new instance of the associated class populated with the data from the newly
inserted row. Changes applied through an UPDATE
operation are
propagated to the corresponding cached object. If the cache does not contain an object
corresponding to the updated row, then the cache is unchanged by default. To change the
default behavior, see HonorRedundantInsert Property. A
DELETE
operation results in the removal of the corresponding object
from the cache, if one exists.
Parent topic: How Does HotCache Work
JPA Relationship Support
HotCache does not support the JPA relationship mappings one-to-one, one-to-many, many-to-one, and many-to-many. However HotCache does support JPA embeddable classes and JPA element collections. Embeddable classes and element collections can be used with HotCache to model relationships between domain objects. Domain objects used with HotCache may also refer to each other by an identifier (analogous to foreign keys in a relational database).
As a performance optimization, when using JPA element collections with HotCache, it is suggested to configure GoldenGate with an ADD TRANDATA
command specifying the column in the element collection table that is the foreign key to the parent table. The optimization allows HotCache to efficiently find the cache entry to update when a row in the element collection table changes.
Parent topic: How Does HotCache Work
Prerequisites
Setting up a database includes:
-
creating a database and tables
-
granting user permissions
-
enabling logging
-
provisioning the tables with data
Example 2-5 illustrates a list of sample commands for the Oracle Database that creates a user named csdemo
and grants user permissions to the database.
Note the ALTER
DATABASE
ADD
SUPPLEMENTAL
LOG
DATA
command. When supplemental logging is enabled, all columns are specified for extra logging. At the very least, minimal database-level supplemental logging must be enabled for any change data capture source database. If the values of primary key columns in a database table can change, it is important to include the following commands for Oracle Database: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
and ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
.
Example 2-5 Sample Commands to Create a User, Grant Permissions, and Enable Logging
CREATE USER csdemo IDENTIFIED BY csdemo; GRANT DBA TO csdemo; grant alter session to csdemo; grant create session to csdemo; grant flashback any table to csdemo; grant select any dictionary to csdemo; grant select any table to csdemo; grant select any transaction to csdemo; grant unlimited tablespace to csdemo; ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
The instructions also assume that you have installed Oracle GoldenGate and started the manager. This includes the following tasks:
-
downloading and installing Oracle GoldenGate
-
running
ggsci
to create the GoldenGate subdirectories -
creating a manager parameter (
mgr.prm
) file, specifying the listener port -
adding JVM libraries to the libraries path
-
starting the manager
- Installing Oracle GoldenGate in the Oracle GoldenGate Microservices Documentation.
-
Installing Oracle GoldenGate for Big Data in Installing and Upgrading Oracle GoldenGate for Big Data.
-
Configuring Oracle GoldenGate for Oracle Database in the Oracle GoldenGate Microservices Documentation.
-
Oracle GoldenGate Java Delivery in Administering Oracle GoldenGate for Big Data.
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
Configuring GoldenGate
Note:
The sample scripts provided in this section are intended only to be introductory. For a comprehensive list of configuration tasks, see Configuring Oracle GoldenGate for Oracle in the Oracle GoldenGate Microservices Documentation and Getting Started with Oracle GoldenGate (Classic) for Big Data in Using Oracle GoldenGate for Big Data.This section includes the following topics:
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
Monitor Table Changes
Indicate the table that you want to monitor for changes by using the ADD
TRANDATA
command. The ADD
TRANDATA
command can be used on the command line or as part of a ggsci
script. For example, to monitor changes to tables in the csdemo
schema, use the following command:
ADD TRANDATA csdemo.*
Example 2-6 illustrates a sample ggsci
script
named cs-cap.ggsci
.
-
The script starts the manager and logs into the database. It stops and deletes any running extract named
cs-cap
. -
The
ADD
TRANDATA
command instructs the extract that tables namedcsdemo*
should be monitored for changes. -
The
SHELL
command deletes all trail files in thedirdat
directory to ensure that if the extract is being recreated, there will be no old trail files. Note that therm -f
command is platform-specific. An extract namedcs-cap
is created using parameters from thedirprm/cs-cap.prm
file. A trail is added atdirdat/cs
from the extractcs-cap
file. -
The
start
command starts thecs-cap.ggsci
script. -
The
ADD
EXTRACT
command automatically uses thecs-cap.prm
file as the source of parameters, so aPARAMS
dirprm/cs-cap.prm
, statement is not necessary.
Example 2-6 Sample GoldenGate Capture
ggsci
Script to Monitor Table Changes
start mgr DBLOGIN USERID csdemo, PASSWORD csdemo STOP EXTRACT cs-cap DELETE EXTRACT cs-cap ADD TRANDATA csdemo.* ADD EXTRACT cs-cap, integrated tranlog, begin now SHELL rm -f dirdat/cs* ADD EXTTRAIL dirdat/cs, EXTRACT cs-cap start cs-cap
Parent topic: Configuring GoldenGate
Filter Changes Made by the Current User
Configure GoldenGate to ignore changes made by the user that the Coherence CacheStores are logged in as. This avoids GoldenGate processing any changes made to the database by Coherence that are already in the cache.
The TranLogOptions
excludeUSER
command can be used on the command line or in a ggsci
script. For example, the following command instructs GoldenGate extract process to ignore changes to the database tables made by the Coherence CacheStore user logged in as csdemo
.
TranLogOptions excludeUser csdemo
Example 2-7 illustrates a sample extract .prm
file named cs-cap.prm
. The user that the Coherence CacheStore is logged in as is csdemo
. The EXTRAIL
parameter identifies the trail as dirdat/cs
. The BR
BROFF
parameter controls the Bounded Recovery (BR) feature. The BROFF
value turns off Bounded Recovery for the run and for recovery. The GETUPDATEBEFORES
parameter indicates that the before images of updated columns are included in the records that are processed by Oracle GoldenGate. The TABLE
parameter identifies csdemo.*
as the tables that should be monitored for changes. The TranLogOptions
excludeUSER
parameter indicates that GoldenGate should ignore changes to the tables made by the Coherence CacheStore user logged in as csdemo
.
Note:
TheOverwriteMode
option is
not applicable in Oracle GoldenGate for Big Data.
Example 2-7 Sample Extract .prm
File
for the GoldenGate Capture
EXTRACT cs-cap
USERID csdemo, PASSWORD csdemo
LOGALLSUPCOLS
UPDATERECORDFORMAT COMPACT
EXTTRAIL dirdat/cs
BR BROFF
getUpdateBefores
TABLE csdemo.*;
TranLogOptions excludeUser csdemo --ignore changes made by csuser
For details on available configuration options for capture, see Extract in the Oracle GoldenGate Microservices Documentation.
Parent topic: Configuring GoldenGate
Configuring HotCache
persistence.xml
file. See How Does HotCache Work. The connection from HotCache to the Coherence cluster can be made by using Coherence*Extend (TCP), or the HotCache JVM can join the Coherence cluster as a member.
The following sections describe the properties needed to configure HotCache and provide details about connecting with Coherence*Extend:
- Create a Properties File with GoldenGate for Java Properties
- Add JVM Boot Options to the Properties File
- Provide Coherence*Extend Connection Information
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
Create a Properties File with GoldenGate for Java Properties
Create a text file with the filename extension .properties
.
In the file, enter the configuration for HotCache. A minimal configuration should
contain the list of event handlers and the fully-qualified Java class of the event
handler.
Note:
The path to the .properties
file must be set in the
HotCache replicat TARGETDB
parameter in a .prm
file, for example:
TARGETDB LIBFILE libggjava.so SET property=/home/oracle/gg/hotcache.properties
Example 2-8 illustrates a .properties
file that contains the minimal configuration for a HotCache project. The following properties are used in the file:
-
gg.handlerlist=hotcache
The
gg.handlerlist
property specifies a comma-separated list of active handlers. This example defines the logical namehotcache
as database change event handler. The name of a handler can be defined by the user, but it must match the name used in thegg.handler.{
name}
.type property in the following bullet. -
gg.handler.hotcache.type=[oracle.toplink.goldengate.CoherenceAdapter|oracle.toplink.goldengate.CoherenceAdapter1220]
The
gg.handler.{name}.type
property defines the handler for HotCache. The{name}
field should be replaced with the name of an event handler listed in thegg.handlerlist
property. The only handlers that can be set for HotCache areoracle.toplink.goldengate.CoherenceAdapter
ororacle.toplink.goldengate.CoherenceAdapter1220
. Useoracle.toplink.goldengate.CoherenceAdapter1220
with GoldenGate Application Adapters release 12.2.0 or later. Useoracle.toplink.goldengate.CoherenceAdapter
with GoldenGate Application Adapters releases earlier than 12.2.0. -
gg.classpath
filesThe following is a list of directories and JAR files for the gg.handler(s) and their dependencies.
-
coherence-hotcache.jar
– contains the Oracle Coherence GoldenGate HotCache libraries -
javax.persistence.jar
– contains the Java persistence libraries -
eclipselink.jar
– contains the EclipseLink libraries -
toplink-grid.jar
– contains the Oracle TopLink libraries required by HotCache -
domain classes – the JAR file or directory containing the user classes cached in Coherence that are mapped with JPA for use in HotCache. Also, the Coherence configuration files,
persistence.xml
file, and anyorm.xml
file.
-
There are many other properties that can be used to control the behavior of the GoldenGate Java Delivery. See Java Delivery Properties in Administering Oracle GoldenGate for Big Data.
Example 2-8 .properties File for a HotCache Project
# ====================================================================
# List of active event handlers
# ====================================================================
gg.handlerlist=hotcache
# ====================================================================
# HotCache event handler
# ====================================================================
gg.handler.hotcache.type=oracle.toplink.goldengate.CoherenceAdapter1220
# ======================================
# HotCache handler dependency jars
# ======================================
# Set gg.classpath with following:
# persistence unit name, application jar(s), directory containing coherence configuration files,
# $GGBD_HOME/dirprm, coherence.jar, coherence-hotcache, jar, eclipselink.jar,
# jakarta.persistence.jakarta.persistence-api.jar
, and toplink-grid.jar from a Coherence
# installation, as well as a JDBC driver jar for your database.
gg.classpath=<list of jars and directories separated by OS specific classpath separator>
# ======================================
# Options for HotCache JVM
# ======================================
jvm.bootoptions=-Djava.class.path=dirprm:ggjava/ggjava.jar -Xmx512M -Xms32M -Dtoplink.goldengate.persistence-unit=employee -Dcoherence.distributed.localstorage=false -Dcoherence.cacheconfig=/home/oracle/cgga/workspace/CacheStoreDemo/client-cache-config.xml
# Note that if you are using a windows machine, you need to replace the : with a ; for both gg.classpath and java.class.path.
Parent topic: Configuring HotCache
Add JVM Boot Options to the Properties File
This section describes the properties that must appear in the JVM boot
options section of the .properties
file. These options are defined by
using the jvm.bootoptions
property. A sample
jvm.bootoptions
listing is illustrated in JVM boot
options
section of Example 2-8.
This section includes the following topics:
Parent topic: Configuring HotCache
Java Classpath Files
The following is a list of directories and JAR files that should be included in the
java.class.path
property.
-
ggjava.jar
– contains the GoldenGate Java Delivery Adapter libraries -
dirprm
– the GoldenGatedirprm
directoryNote:
Thedirprm
directory is included here since it could include custom logging properties file required for logging initialization that occurs beforegg.classpath
is added to classloader. This directory can be moved togg.classpath
if it does not include any logging property or jar files. See Configuring Java Delivery.
Parent topic: Add JVM Boot Options to the Properties File
HotCache-related Properties
The toplink.goldengate.persistence-unit
property is required as it identifies the persistence unit defined in persistence.xml
file that HotCache should load. The persistence unit contains information such as the list of participating domain classes, configuration options, and optionally, database connection information.
The toplink.goldengate.on-error
property is optional. It controls how the adapter responds to errors while processing a change event. This response applies to both expected optimistic lock exceptions and to unexpected exceptions. This property is optional, as its value defaults to "Refresh". Refresh causes the adapter to attempt to read the latest data for a given row from the database and update the corresponding object in the cache. Refresh requires a database connection to be specified in the persistence.xml
file. This connection will be established during initialization of HotCache. If a connection cannot be made, then an exception is thrown and HotCache will fail to start.
The other on-error strategies do not require a database connection. They are:
-
Ignore
—Log the exception only. The cache may be left with stale data. Depending on application requirements and cache eviction policies this may be acceptable. -
Evict
—Log a warning and evict the object corresponding to the change database row from the cache -
Fail
—Throw an exception and exit HotCache
Parent topic: Add JVM Boot Options to the Properties File
Coherence-related Properties
Any Coherence property can be passed as a system property in the Java boot options. The coherence.distributed.localstorage
system property with a value of false
is the only Coherence property that is required to be passed in the Java boot options. Like all Coherence properties, precede the property name with the -D
prefix in the jvm.bootoptions
statement, for example:
-Dcoherence.distributed.localstorage=false
Parent topic: Add JVM Boot Options to the Properties File
Logging Properties
To configure Java Delivery logging for Oracle GoldenGate for Big Data, see Logging Properties in Administering Oracle GoldenGate for Big Data . In the Oracle GoldenGate for Big
Data installation directory, examples of logging properties files are available for
jdk
, logback
, and log4j2
under the
AdapterExamples/java-delivery/sample-dirprm
directory.
Parent topic: Add JVM Boot Options to the Properties File
Provide Coherence*Extend Connection Information
The connection between HotCache and the Coherence cluster can be made with Coherence*Extend. For more information on Coherence*Extend, see Developing Remote Clients for Oracle Coherence.
The Coherence configuration files must be in a directory referenced by the
gg.classpath
entry in the .properties
file. For an
example, see the gg.classpath
files.
Example 2-9 illustrates the section of a client cache configuration file that uses
Coherence*Extend to connect to the Coherence cluster. In the client cache configuration
file, Coherence*Extend is configured in the <remote-cache-scheme>
section. For additional options for configuring a remote-cache-scheme, see Overview of Configuring Extend Clients in Developing
Remote Clients for Oracle Coherence.
Example 2-9 Coherence*Extend Section of a Client Cache Configuration File
<cache-config> ... <caching-schemes> <remote-cache-scheme> <scheme-name>CustomRemoteCacheScheme</scheme-name> <service-name>CustomExtendTcpCacheService</service-name> <initiator-config> <tcp-initiator> <remote-addresses> <socket-address> <address>localhost</address> <port>9099</port> </socket-address> </remote-addresses> </tcp-initiator> <outgoing-message-handler> ... </outgoing-message-handler> </initiator-config> </remote-cache-scheme> ... </cache-config>
Example 2-10 illustrates the section of a server cache configuration file that listens for Coherence*Extend connections. In the server cache configuration file, Coherence*Extend is configured in the <proxy-scheme>
section. By default, the listener port for Coherence*Extend is 9099
.
Example 2-10 Coherence*Extend Section of a Server Cache Configuration File
<cache-config> ... <caching-schemes> ... <proxy-scheme> <scheme-name>CustomProxyScheme</scheme-name> <service-name>CustomProxyService</service-name> <thread-count>2</thread-count> <acceptor-config> <tcp-acceptor> <local-address> <address>localhost</address> <port>9099</port> </local-address> </tcp-acceptor> </acceptor-config> <load-balancer>proxy</load-balancer> <autostart>true</autostart> </proxy-scheme> </caching-schemes> </cache-config>
Parent topic: Configuring HotCache
Configuring the GoldenGate Big Data Java Delivery Adapter
This section includes the following topic:
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
Edit the HotCache Replicat Parameter File
This section describes the parameters that can be defined in the replicat
.prm
file for a GoldenGate Big Data Java Delivery adapter. The
parameters that are illustrated in Example 2-11 constitute a minimal configuration for a HotCache project.
For details on creating a replicat parameter file, see Basic Parameters for Different Replicat Modes in the Oracle GoldenGate Microservices Documentation.
-
TARGETDB LIBFILE libggjava.so SET property=/home/oracle/gg/hotcache.properties
-
GROUPTRANSOPS 1
The
GROUPTRANSOPS
parameter controls transaction grouping by the GoldenGate replicat process. A value of1
tells the GoldenGate replicat process to honor source database transaction boundaries in the trail file. A value greater than1
tells the GoldenGate replicat process to group operations from multiple source database transactions into a single target transaction. See GROUPTRANSOPS in Reference for Oracle GoldenGate for Windows and UNIX. -
MAP scott.*, TARGET scott.*;
The MAP parameter tells the GoldenGate replicat process how to map source database tables to the replication target. The parameter syntax assumes the replication target is a relational database. For HotCache it is appropriate to specify an identical mapping. See TABLE and MAP Options in Reference for Oracle GoldenGate.
Example 2-11 illustrates a sample .prm
file for a GoldenGate Big
Data Java Delivery adapter.
Example 2-11 Sample .prm Parameter File for a GoldenGate Big Data Java Delivery adapter
REPLICAT hotcache TARGETDB LIBFILE libggjava.so SET property=/home/user/project/hotcache.properties GROUPTRANSOPS 1 GetUpdateBefores MAP scott.*, TARGET scott.*;
Configuring the Coherence Cache Servers
-
coherence-hotcache.jar
– contains the Oracle Coherence GoldenGate HotCache libraries -
javax.persistence.jar
– contains the Java persistence libraries -
eclipselink.jar
– contains the EclipseLink libraries -
toplink-grid.jar
– contains the Oracle TopLink libraries required by HotCache -
domain classes – the JAR file or directory containing the user classes cached in Coherence that are mapped with JPA for use in HotCache.
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
Using Portable Object Format with HotCache
(pof-config.xml)
to allow for HotCache and TopLink Grid framework classes to be registered.The pof-config.xml
file must include the coherence-hotcache-pof-config.xml
file and must register the TopLinkGridPortableObject
user type and TopLinkGridSerializer
as the serializer. The <type-id>
for each class must be unique and must match across all cluster instances. See Registering POF Objects in Developing Applications with Oracle Coherence.
The <allow-interfaces>
element must be set to true
to allow you to register a single class for all implementors of the TopLinkGridPortableObject
interface.
Example 2-12 illustrates a sample pof-config.xml
file for HotCache. The value integer_value
represents a unique integer value greater than 1000
.
Example 2-12 Sample POF Configuration File for HotCache
<?xml version='1.0'?>
<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof-config
coherence-pof-config.xsd">
<user-type-list>
<include>coherence-hotcache-pof-config.xml</include>
<!-- User types must be above 1000 -->
...
<user-type>
<type-id><integer_value
></type-id>
<class-name>oracle.eclipselink.coherence.integrated.cache.TopLinkGridPortableObject</class-name>
<serializer>
<class-name>oracle.eclipselink.coherence.integrated.cache.TopLinkGridSerializer</class-name>
</serializer>
</user-type>
...
</user-type-list>
<allow-interfaces>true</allow-interfaces>
...
</pof-config>
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
Configuring HotCache JPA Properties
@Property
annotation on the JPA entity class or by a <property>
element in the persistence.xml
file. The latter takes precedence in the event of conflicting configuration.
This section includes the following topics:
- EnableUpsert Property
- HonorRedundantInsert Property
- SyntheticEvent Property
- eclipselink.cache.shared.default Property
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
EnableUpsert Property
EnableUpsert
The EnableUpsert
property controls whether HotCache inserts a cache entry when an update operation is received in the GoldenGate trail file but no corresponding cache entry is present in cache at the entity key. By default, HotCache ignores updates to absent entities. Set this property to true
if you want HotCache to insert missing entities into the cache when update operations are received in the trail file. The default value of this property is false
.
Setting this property to true
can facilitate warming caches in an event-driven manner if it is likely that entities will be accessed from the cache after their corresponding records are updated in the underlying database.
Note:
There are risks to consider when using this property:
-
The entity to insert is read from the database, as the trail file may not contain values for all fields of the entity to be inserted. This can reduce the throughput of the HotCache process by waiting on database reads.
-
Cache capacity can be exhausted if more rows in the DB are updated than the number of entities in the cache for which capacity was provisioned.
Entity Class Annotation
@Property(name = "EnableUpsert", value = "false",valueType = boolean.class)
Persistence XML Property
<property name="[fully qualified entity class name].EnableUpsert" value="[true|false]"/>
Parent topic: Configuring HotCache JPA Properties
HonorRedundantInsert Property
HonorRedundantInsert
The HonorRedundantInsert
property controls whether HotCache honors an insert operation in the GoldenGate trail file when a cache entry at that key is already present. By default, HotCache ignores a redundant insert operation. However, when a JPA entity is mapped to a complex materialized view in Oracle Database and a row is updated in a table underlying that materialized view (thus updating one or more rows of the materialized view), Oracle Database inserts a new row into the materialized view with the same PK as an existing row but with a new rowid and deletes the existing row. Therefore, HotCache sees a redundant insert operation that really represents an update to the cached JPA entity. Users in this situation should also consider suppressing replication of delete operations on that materialized view through the use of GoldenGate configuration; otherwise, the cached entity is deleted by HotCache. The default value of this property is false
.
Entity Class Annotation
@Property(name = "HonorRedundantInsert", value = "false",valueType = boolean.class)
Persistence XML Property
<property name="[fully qualified entity class name].HonorRedundantInsert" value="[true|false]"/>
Parent topic: Configuring HotCache JPA Properties
SyntheticEvent Property
SyntheticEvent
The SyntheticEvent
property controls whether cache writes by HotCache are synthetic or not. Synthetic writes to Coherence caches do not trigger events in Coherence; they do not engage Federated Caching; and they do not call Coherence CacheStore
implementations. Set this property to false
for a JPA entity class if you want cache writes by HotCache for that class to be non-synthetic so that events are triggered, Federated Caching is engaged, and CacheStore
implementations are called (if any of those are configured for the entity class cache). The default value of this property is true
for every entity class.
Note:
There is a risk of infinite replication loops if the SyntheticEvent
is set to true
for an entity class and a CacheStore
implementation is configured on that entity class cache and writing to the same database HotCache is replicating to Coherence. This risk can be mitigated by filtering transactions by database user. See Filter Changes Made by the Current User.
Entity Class Annotation
@Property(name = "SyntheticEvent", value = "[true|false]", valueType = boolean.class)
Persistence XML Property
<property name="[fully qualified entity class name].SyntheticEvent" value="[true|false]"/>
Parent topic: Configuring HotCache JPA Properties
eclipselink.cache.shared.default Property
eclipselink.cache.shared.default
The eclipselink.cache.shared.default
property is used to enable the EclipseLink internal shared cache. It is important to disable the internal shared cache in the HotCache JVM by setting the property to false
in the persistence.xml
file.
Persistence XML Property
<property name=" eclipselink.cache.shared.default" value="false"/>
Parent topic: Configuring HotCache JPA Properties
Warming Caches with HotCache
This section includes the following topics:
- Create and Run an Initial Load Extract
- Create and Run a Cache Warmer Replicat
- Capturing Changed Data While Warming Caches
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
Create and Run an Initial Load Extract
IL0001
, IL0002
, etc... in the GG_HOME/dirdat
directory. If no files are generated, then review the GG_HOME/dirrpt/initload.rpt
file.
Parent topic: Warming Caches with HotCache
Create and Run a Cache Warmer Replicat
Parent topic: Warming Caches with HotCache
Capturing Changed Data While Warming Caches
- Start the normal source extract process that captures change data from the database’s redo logs, but do not start the normal HotCache replicat process that refreshes Coherence caches with that change data.
- Start the initial load extract process to select the initial data set from the database.
- Run the cache warming replicat process to warm Coherence caches with the initial data set.
- Verify that the initial load has completed correctly by comparing the number of rows extracted from the database by GoldenGate (see
initload.rpt
) with the number of entries in the target Coherence caches according to Coherence MBeans or command-line interface commands. - Start the normal HotCache replicat process to refresh Coherence caches with change data.
Parent topic: Warming Caches with HotCache
Implementing High Availability for HotCache
In best-practice deployments, Coherence cache services and proxy services are already highly available due to redundancy of service members (for example, multiple cache server processes and multiple proxy server processes) and due to built-in automatic failover capabilities within Coherence. For example, if a proxy server should fail, then Coherence*Extend clients that are using the proxy server automatically fail over to another proxy server. Likewise, if a cache server should fail then another cache server assumes responsibility for its data and client interactions with that data automatically redirect to the new cache server owning the data.
Making the HotCache client itself highly available relies on standard GoldenGate HA techniques since the HotCache JVM runs embedded in a GoldenGate process.
GoldenGate implements “single server” HA through AUTOSTART and AUTORESTART parameters enforced by the Manager process in a GoldenGate installation. The Manager process automatically starts registered GoldenGate processes configured with AUTOSTART. It also detects the death of (and automatically restarts), registered GoldenGate processes configured with AUTORESTART.
To protect against failure of the Manager process itself or the host on which it runs or the network connecting that host, GoldenGate relies on Oracle Clusterware to detect the death of the active GoldenGate installation and fail over to a passive GoldenGate installation.
GoldenGate high availability is discussed in the Oracle GoldenGate Classic Architecture with Oracle Real Application Clusters Configuration Best Practices white paper.
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
Support for Oracle Data Types
SDO_GEOMETRY
from the Oracle Spatial and Graph option for Oracle Database and XMLType
in all Oracle Database editions.
It is important to understand that data is presented to EclipseLink differently when used in HotCache than when used in the typical JPA scenario. In the typical JPA scenario, EclipseLink interacts with the database through a JDBC connection and EclipseLink consumes data as presented by the JDBC API and driver-specific extensions (for example an SDO_GEOMETRY
column is represented as an instance of java.sql.Struct
). Whereas in HotCache, data is read from a GoldenGate trail file; there is no JDBC connection involved. Therefore EclipseLink consumes the GoldenGate representation of data as opposed to the JDBC representation of data. For example, GoldenGate represents an SDO_GEOMETRY
column as an XML document and not as an instance of java.sql.Struct
.
These differences in data representation may necessitate the use of HotCache-specific EclipseLink converters when using EclipseLink within HotCache that take the place of standard EclipseLink converters used in typical JPA scenarios. See @Converter in Java Persistence API (JPA) Extensions Reference for EclipseLink. The following sections describe HotCache support for specific Oracle Database data types supported by EclipseLink and how to configure EclipseLink within HotCache to use those data types.
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
Support for SDO_GEOMETRY
EclipseLink supports the Oracle Spatial and Graph option of Oracle Database by mapping SDO_GEOMETRY
columns to instances of oracle.spatial.geometry.JGeometry
(the Java class shipped with the Oracle Spatial and Graph option). See Using Oracle Spatial and Graph in Solutions Guide for EclipseLink.
Therefore, HotCache supports mapping columns of type SDO_GEOMETRY
to instances of oracle.spatial.geometry.JGeometry
bound to fields of JPA entities. This support requires configuring a HotCache-specific EclipseLink Converter of class oracle.toplink.goldengate.spatial.GoldenGateJGeometryConverter
as shown in the following example.
import javax.persistence.Access;
import javax.persistence.AccessType;
import javax.persistence.Convert;
import javax.persistence.Converter;
import javax.persistence.Entity;
import oracle.spatial.geometry.JGeometry;
import oracle.toplink.goldengate.spatial.GoldenGateJGeometryConverter;
@Entity
@Converter(name=”JGeometry”, converterClass= GoldenGateJGeometryConverter.class)
public class SpatialEntity {
private JGeometry geometry;
@Access(AccessType.PROPERTY)
@Convert(“JGeometry”)
public JGeometry getGeometry() {
return geometry;
}
This converter converts the GoldenGate XML representation of an SDO_GEOMETRY
column into an instance of oracle.spatial.geometry.JGeometry
bound to a field of a JPA entity. The GoldenGateJGeometryConverter
class is contained in coherence-hotcache.jar
which should already be on the classpath of the HotCache JVM and Coherence cache server JVMs used in HotCache deployments (along with the eclipselink.jar
file on which it depends). However the JGeometry
class is contained in sdoapi.jar
from an installation of Oracle Spatial and Graph option. The sdoapi.jar
file must be on the classpath of the HotCache JVM, and any other JVM where the JPA entity containing a JGeometry
field will be deserialized.
The oracle.spatial.geometry.JGeometry
class implements java.io.Serializable
, so JPA entities with JGeometry
fields cached in Coherence can be serialized with java.io.Serializable
without any additional configuration. To use Coherence’s Portable Object Format (POF) to serialize a JPA entity with a JGeometry
field, the JGeometrySerializer
must be added to the POF configuration file used in the Coherence deployment, as in the following example.
<user-type>
<type-id>1001</type-id><!—use a type-id value above 1000 that doesn’t conflict with other POF type-ids-->
<class-name>oracle.spatial.geometry.JGeometry</class-name>
<serializer>
<class-name>oracle.spatial.geometry.JGeometryPofSerializer</class-name>
</serializer>
</user-type>
The oracle.spatial.geometry.JGeometryPofSerializer
class is contained in coherence-hotcache.jar
, which must be on the classpath of any JVM that will serialize or deserialize a JPA entity with a JGeometry
field using POF.
Parent topic: Support for Oracle Data Types
Support for XMLType
EclipseLink supports the Oracle Database XMLType
data type by mapping XMLType
columns to instances of java.lang.String
or org.w3c.dom.Document
(depending on the type of the mapped field in the JPA entity). See DirectToXMLTypeMapping in EclipseLink API Reference and Mapping XMLTYPE in the On Persistence blog.
Therefore, HotCache supports mapping columns of type XMLType
to instances of java.lang.String
or org.w3c.dom.Document
bound to fields of JPA entities. This support requires configuring a standard EclipseLink DirectToXMLTypeMapping
.
GoldenGate must be configured to use integrated capture mode for support of
XMLType
columns. See Details of Support for Oracle Data Types and
Objects in Using Oracle
GoldenGate with Oracle Database.
Parent topic: Support for Oracle Data Types
Configuring Multi-Threading in HotCache
Transactions and their operations appear in the trail file in the order in which they were committed in the source database. By default, HotCache applies operations one at a time on a single thread to ensure the operations are applied to the cache in the exact same order in which they were applied to the source database. When using multi-threading, operations can be applied in a different order than that in which they were applied to the source database tables and can result in correctness risks.
When determining the potential risk, consider the following examples:
-
If one database transaction inserts a row in a table and the next database transaction deletes that row, then applying operations out of order can leave an object in the cache whose corresponding database row is deleted.
-
If one database transaction updates a column to an older value and the next database transaction updates that column to a newer value, then applying operations out of order can leave the older value in the cached object instead of the newer value. (You can use the JPA optimistic locking features, which are supported by HotCache, to mitigate this particular update risk).
If you determine that using multiple threads to apply trail file operations to Coherence caches poses no data correctness risks in the system using HotCache, then HotCache can be configured to use multi-threading as follows:
-
Edit the GoldenGate Java Delivery Adapter properties file and configure the HotCache event handler to use transaction mode:
gg.handlerlist=hotcache goldengate.handler.hotcache.type=oracle.toplink.goldengate.CoherenceAdapter1220 goldengate.handler.hotcache.mode=tx
By default, GoldenGate Java Delivery Adapter event handlers use operation mode. In operation mode (
op
), event handlers process operations one at a time. In transaction mode (tx
), event handlers process all operations in a transaction at a time. -
Edit the GoldenGate Java Delivery Adapter properties file and set the
coherence.hotcache.concurrency
system property on the HotCache JVM with a value between one and eight times the number of cores on the JVM host, inclusive (as reported byjava.lang.Runtime.getAvailableProcessors()
). For example:jvm.bootoptions=-Dcoherence.hotcache.concurrency=16 …
The value of this property determines the number of threads HotCache uses to concurrently apply trail file operations to Coherence caches.
-
Edit the HotCache replicat
.prm
file and set theGROUPTRANOPS
property. A value of1
causes source database transaction boundaries to be honored. A value greater than1
causes transaction grouping within the GoldenGate replicat. The default value is1000
.
Summary of Hot Cache Thread Behavior
Assuming HotCache is run in a GoldenGate replicat process as recommended, the risks stemming from conflicting source database transactions only materialize if the GROUPTRANOPS
property is configured to a value other than one 1
. A value of 1
causes the source database transaction boundaries and sequencing to be honored by the HotCache replicat. Therefore, the operations in one transaction are applied in parallel followed by the operations in the next transaction and so on. The GROUPTRANOPS
property default is 1000
, which groups trail file operations from multiple successive source database transactions into one target transaction of at least 1,000 operations. The likelihood of data correctness risks materializing when the GROUPTRANOPS
parameter is set to greater than one is equivalent to the likelihood of conflicting operations within the grouped source database transactions, given the magnitude of the GROUPTRANOPS
property value and the write rate and volume of the source database. See GROUPTRANSOPS in Reference for Oracle GoldenGate for Windows and UNIX.
The following table summarizes the HotCache thread behavior depending on the values
of the GoldenGate Java Delivery Adapter mode
property and the
coherence.hotcache.concurrency
property.
Table 2-1 Hot Cache Thread Behavior
Mode | Concurrency | Behavior |
---|---|---|
|
N/A |
In op mode, HotCache applies trail file operations one at a
time on a single thread (the GoldenGate Java Delivery Adapter
thread) as each operation is read from the trail file. This is the
HotCache default behavior. The value of the concurrency property is
not considered in operation mode.
|
|
1 |
In tx mode with a concurrency property value of
1 , HotCache iterates and applies a transaction
worth of trail file operations on a single thread (the GoldenGate
Java Delivery Adapter thread). The group of operations comprising
the transaction is determined by the value of the GoldenGate
replicat GROUPTRANOPS property. The default value
of the concurrency property is 1 . This
configuration may exhibit greater throughput than the operation mode
configuration, even though it is still single-threaded and therefore
poses no data correctness risks.
|
|
>1 |
In tx mode with a concurrency property value greater than 1 , HotCache applies a transaction worth of operations in parallel on multiple HotCache threads. The group of operations comprising the transaction is determined by the value of the GoldenGate replicat GROUPTRANOPS property. This configuration should exhibit greater throughput than single-threaded configurations and throughput generally increases with the number of threads configured to a maximum of eight times the number of cores on the HotCache host.
|
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
Managing HotCache
This section includes the following topics:
- CoherenceAdapterMXBean
- Understanding the HotCache Report
- Monitoring HotCache Using the Coherence VisualVM Plug-In
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache
CoherenceAdapterMXBean
The CoherenceAdapterMXBean
MBean represents a Golden Gate HotCache adapter and provides operational and performance statistics. Zero or more instances of this managed bean are created: one managed bean instance for each adapter instance.
The object name of the MBean is:
Type=CoherenceAdapter,name=replicat name,member=member name
To view the CoherenceAdapterMXBean
MBean from an MBean browser, you must enable Coherence management. If you are new to Coherence JMX management, see Using JMX to Manage Oracle Coherence.
Attributes
Table 2-2 describes the attributes for CacheMBean
.
Table 2-2 CoherenceAdapterMXBean
Attribute | Type | Access | Description |
---|---|---|---|
|
|
read-only |
The names of the caches that were refreshed by the CoherenceAdapter |
|
|
read-only |
Summary statistics about the execution time for each operation in nanoseconds since the statistics were last reset |
|
|
read-only |
Summary statistics about the execution time for each transaction in nanoseconds since the statistics were last reset |
|
|
read-only |
Summary statistics about the number of invocations for each operation since the statistics were last reset |
|
|
read-only |
Summary statistics about the execution time for each operation in nanoseconds since this method was last called |
|
|
read-only |
Summary statistics about operation replication lag in milliseconds since this method was last called |
|
|
read-only |
The aggregate number of operations processed since the statistics were last reset |
|
|
read-only |
Summary statistics about operation replication lag in milliseconds since the statistics were last reset |
|
|
read-only |
Summary statistics about the number of operations for each transaction since the statistics were last reset |
|
|
read-only |
Execution time summary statistics in nanoseconds for each cache for each operation type |
|
|
read-only |
The time at which the CoherenceAdapter was started |
|
|
read-only |
The name of the trail file currently being read |
|
|
read-only |
The position in the trail file of the last successfully-processed operation |
Operations
The CoherenceAdapterMXBean
MBean includes a resetStatistics
operation that resets all cache statistics.
Parent topic: Managing HotCache
Understanding the HotCache Report
The HotCache report includes operational settings and performance statistics. The statistical data is collected from the CoherenceAdapterMXBean
MBean and presented over time making it ideal for discovering performance trends and troubleshooting potential performance issues. The name of the HotCache report is timestamp-hotcache.txt
where the timestamp is in YYYYMMDDHH format. For example, a file named 2009013101-hotcache.txt
represents a HotCache report for January 31, 2009 at 1:00 a.m.
To view the HotCache report, you must enable Coherence reporting and you must configure the report-all report group. If you are new to Coherence reporting, see Using Oracle Coherence Reporting.
Table 2-3 describes the contents of the HotCache report.
Table 2-3 Contents of the HotCache Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts, and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The user-given name of the HotCache event handler from the GoldenGate HotCache properties file |
|
|
The Coherence member name where the HotCache adapter runs |
|
|
The time when the Coherence HotCache adapter started |
|
|
The number of transaction operations processed |
|
|
The name of the Golden Gate trail file that contains transaction operations |
|
|
The position in the trail file of the last successfully-processed operation |
|
|
The average number of operations processed for each transaction |
|
|
The maximum number of operations processed for each transaction |
|
|
The minimum number of operations processed for each transaction |
|
|
The average number of entry processor invocations that are performed for each operation |
|
|
The maximum number of entry processor invocations that are performed for each operation |
|
|
The minimum number of entry processor invocations that are performed for each operation |
|
|
The average execution time for each operation since the last sample in nanoseconds |
|
|
The average execution time for each operation in nanoseconds |
|
|
The maximum execution time for each operation in nanoseconds |
|
|
The minimum execution time for each operation in nanoseconds |
|
|
The average execution time for each transaction in nanoseconds |
|
|
The maximum execution time for each transaction in nanoseconds |
|
|
The maximum execution time for each transaction in nanoseconds |
|
|
The average time in milliseconds between the commit of the database transaction and the processing of the last operation by the HotCache adapter |
|
|
The average time in milliseconds between the commit of the database transaction and the processing of the operation by the HotCache adapter |
|
|
The average time in milliseconds between the commit of the database transaction and the processing of the operation by the HotCache adapter since the last sample |
|
|
The minimum time in milliseconds between the commit of the database transaction and the processing of the operation by the HotCache adapter |
Parent topic: Managing HotCache
Monitoring HotCache Using the Coherence VisualVM Plug-In
The HotCache tab in the Coherence VisualVM Plug-In provides a graphical view of HotCache performance statistics. If you are new to the Coherence VisualVM plug-in, see Using the Coherence VisualVM Plug-In.
The HotCache statistical data is collected from the CoherenceAdapter
MBean and presented over time in both tabular and graph form. The tab displays
statistics for each GoldenGate HotCache member including detail about specific caches
refreshed by that HotCache member. To view data for a specific member, select the member
on the member table. To view data for a specific cache, select the cache on the cache
table.
Use the HotCache tab to get a detailed view of performance statistics and to identify potential performance issues with cache update operations. The HotCache tab includes:
- The minimum, maximum, and average time it takes to update a cache for each operation.
- The minimum, maximum, and average time it takes to update a cache for all the operations in a transaction.
- The total number of entry processor invocations that are performed for each operation.
- The minimum, maximum, and average time for the last operation.
- The minimum, maximum, and average operation replication lag time for the last operation since this MBean attribute value was last sampled. Replication lag is the amount of time between the commit of the database transaction and the processing of the operation by the HotCache adapter.
- The minimum, maximum, and average operation replication lag time since the statistics were last reset.
- The minimum, maximum, and average number of operations for each transaction.
- The minimum, maximum, and average time for each operation type for each cache.
Operations include:
EVICT
,INSERT
,PK_CHANGE
,READ_FROM_DB
,REDUNDANT_INSERT
,REFRESH
,UPDATE
, andUPSERT
.
Parent topic: Managing HotCache
Fixing Issues
If you run into issues while using HotCache with Coherence, you may be able to resolve the issue using one of the following options.
Issue: The following error appears:
WARNING: Illegal reflective access by org.eclipse.persistence.internal.security.PrivilegedAccessHelper (org/eclipse/persistence/eclipselink/<version>/eclipselink-<version>.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
Fix: Add the following JPMS option to the Java command line: --add-opens java.base/java.lang=org.eclipse.persistence.core
For information on why this JPMS option is necessary, see Using Java Modules to Build a Coherence Application in Developing Applications with Oracle Coherence.
Parent topic: Integrating with Oracle Coherence GoldenGate HotCache