Enabling correlator persistence
Before you enable persistence, you should design and develop your application to handle persistence and recovery. See
Designing applications for persistence-enabled correlators.
To enable correlator persistence, you must
Insert the word
persistent before the monitor declaration for each monitor written in EPL that you want to be persistent. For example:
persistent monitor Order {
action onload() {
...
}
}
For a monitor declared as persistent, the correlator persists the state of all monitor instances of that name, and all instances of events that the monitor instances create.
You do not mark event types as persistent. Whether or not an event is persisted depends on whether it is used from a persistent or non-persistent monitor. If an event is on a context queue when the correlator takes a snapshot the event is persisted.
Specify one or more persistence options when you start the correlator. You must always specify the
-P option to enable correlator persistence.
Specify only the -P option to implement default behavior for correlator persistence. To change default behavior, also specify one or more of the options described in the table below. The correlator uses the default when you do not specify an option that indicates otherwise. For example, if you specify -P, -PsnapshotInterval and -PstoreLocation, the correlator uses the values you specify for the snapshot interval and the recovery datastore location and uses the default setttings for all other persistence behavior.
Note: During development of a persistence application, it varies whether you want to specify a persistence option when you start the correlator. In the earlier stages of development, you might choose not to specify a persistence option since you might make many and frequent changes to early versions of your program, thereby making recovery of a previous version impossible. For example, you might have changed the structure and perhaps added new variables. Once your program structure becomes relatively stable, you must take into account what happens during recovery and you will want to define onBeginRecovery() and onConcludeRecovery() actions. These actions never get called in a correlator that was not started with a persistence option. To deploy a persistence application, the correlator must be started with a persistence option.
The following table describes correlator persistence behavior, the default behavior, and the options you can specify to change default behavior.
Correlator Persistence Behavior | Default | Option for Changing |
The correlator waits a specified length of time between snapshots. | 200 milliseconds | -PsnapshotInterval=interval Specify an integer that indicates the number of milliseconds to wait. |
The correlator can automatically adjust the snapshot interval according to application behavior. It can be useful to set this to false to diagnose a problem or test a new feature. | True — the correlator automatically adjusts the snapshot interval. | -PadjustSnapshot=boolean |
The correlator puts the recovery datastore in a specified directory. | The directory in which the correlator was started. That is, the current directory. | -PstoreLocation=path You can specify an absolute or relative path. The directory must exist. |
The correlator copies the snapshot into a specified file. This is the recovery datastore. | persistence.db | -PstoreName=filename Specify a filename without a path. |
For correlators that use an external clock, the correlator uses a specified time of day as its starting time when it restarts. This behavior is useful only for replaying input logs that contain recovery information. | The time of day captured in the last committed snapshot. | -XrecoveryTime num To change the default, specify an integer that indicates seconds since the epoch. |
The correlator can automatically copy the recovery datastore to the input log when a persistence-enabled correlator restarts. | The correlator copies the recovery datastore to the input log. | -noDatabaseInReplayLog You might set this option if you are using an input log as a record of what the correlator received. The recovery datastore is a large overhead that you probably do not need. Or, if you maintain an independent copy of the recovery datastore, you probably do not want a copy of it in the input log. |