In a persistent monitor, you can define one or two actions that the correlator executes as part of the recovery process:

Whether you define zero, one or both actions in each persistent monitor is application-dependent. See Designing applications for persistence-enabled correlators and Sample code for persistence applications.

You can define an event and specify one or both of these actions as fields in the event. If an event defines a recovery action and an instance of the event is live in a persistent monitor, then the correlator calls the action(s) on those objects as well. A live event is reachable from a global variable or listener-captured local variable and consequently is not a candidate for garbage collection.

You can define onBeginRecovery() and onConcludeRecovery() actions in custom aggregate functions in the same way as you define them in events. When an aggregate function contains an onBeginRecovery() or onConcludeRecovery() action this action is called on each custom aggregate function instance in a live query in a persistent monitor along with the onBeginRecovery() and onConcludeRecovery() actions in persistent monitors and events.

The order in which the correlator executes instances of onBeginRecovery() actions and instances of onConcludeRecovery() actions for objects in a monitor is not defined. If a monitor terminates after execution of onBeginRecovery() and before recovered queues have been flushed, the correlator does not call that monitor’s onConcludeRecovery() action (if it has one). If the correlator terminates all of a monitor’s listeners in one execution of onBeginRecovery(), later calls to onBeginRecovery() for that monitor instance still occur because they might instantiate new listeners. If no listeners exist in a monitor after onBeginRecovery() and onConcludeRecovery() have been executed for every object in that monitor, the monitor instance terminates as usual.

See Recovery order for more details about when onBeginRecovery() and onConcludeRecovery() are executed.