This chapter includes the following sections:
To run the Java Delivery and execute the Java application, you only need an existing Oracle GoldenGate trail file. If the trail file does not contain metadata records, a source definitions file is also required to describe the schema for operations in the trail file. For the examples that follow, a simple TCUSTMER and TCUSTORD trail is used (matching the demo SQL provided with the Oracle GoldenGate software download).
To run Java Delivery using Replicat, simply start the Replicat process from GGSCI:
GGSCI> START REPLICAT javarep GGSCI> INFO REPLICAT javarep
The INFO command will return information similar to the following:
REPLICAT JAVAREP Last Started 2015-09-10 17:25 Status RUNNINGCheckpoint Lag 00:00:00 (updated 00:00:00 ago)Log Read Checkpoint File ./dirdat/aa0000002015-09-10 17:50:41.000000 RBA 2702
Alternatively, to run the Java Delivery using the Extract process (Data Pump), start the Extract process from GGSCI:
GGSCI> START EXTRACT javaue GGSCI> INFO EXTRACT javaue
If the Replicat or Extract process is running and, the file handler is being used (as in the preceding example), then you should see the output file output.xml in the Oracle GoldenGate installation directory (the same directory as the Replicat and Extract executables).
If the process does not start or abend, see Checking for Errors.
Note:
Do not modify or delete the checkpoint file on the production system.
There are two possible checkpoint files when using Java Delivery session: the Java Delivery checkpoint and the Replicat or Extract process checkpoint. The Replicat or Extract process always generates a checkpoint file. The Java Delivery checkpoint file is optional and can be controlled by the following property in the Adapter Properties file.
To turn on Java Delivery Checkpoint generation (the default):
goldengate.userexit.nocheckpoint=false
To turn off Java Delivery Checkpoint generation:
goldengate.userexit.nocheckpoint=true
If the Java Delivery checkpointing functionality is enabled then the following property should be set to allow for unique checkpoint file naming:
goldengate.userexit.chkptprefix=something unique
It is considered a best practice not to generate the Java checkpoint file when Java Delivery is hosted in a Replicat process. It is considered a best practice to generate the Java checkpoint file when Java Delivery is hosted in an Exract process. The following subsections discuss the checkpoint handling in Replicat and Extract.
The checkpoint handling in Replicat is more straightforward as it includes logic to pick which one out of the two checkpoint information is of higher priority. The logic is as follows:
If the Java Delivery is started after user manually performed an ADD or ALTER REPLICAT, then the checkpoint information held by Replicat process will be used as the starting position.
If the Java Delivery is started without prior manual intervention to alter checkpoint (for example, upon graceful stop or an abend), then the checkpoint information held by Java module will be used as the starting position.
For example, restarting a Java Delivery using Replicat at the beginning of a trail looks like the following:
Reset the Replicat to the beginning of the trail data:
GGSCI> ALTER REPLICAT JAVAREP, EXTSEQNO 0, EXTRBA 0
Reset the Replicat
GGSCI> START JAVAREP GGSCI> INFO JAVAREP REPLICAT JAVAREP Last Started 2015-09-10 17:25 Status RUNNING Checkpoint Lag 00:00:00 (updated 00:00:00 ago) Log Read Checkpoint File ./dirdat/aa000000 2015-09-10 17:50:41.000000 RBA 2702
It may take a few seconds for the Replicat process status to report itself as running. Check the report file to see if it abended or is still in the process of starting:
GGSCI> VIEW REPORT JAVAREP
In the case where the Java Delivery is restarted after a crash or an abend, the last position kept by the Java module will be used when the application restarts.