Backing Store and Checkpointing

Checkpointing persists the process data to the backing store and cache for use in recovery. At a checkpoint, the values of all process variables are saved to the backing store and cache.

TIBCO BusinessEvents Process Orchestration supports only Shared All as the persistence option and only cache-aside as the backing store write option. See TIBCO BusinessEvents Architect’s guide for more information on backing store.

Note: Process Orchestration does not support the Shared Nothing persistent option and the write-behind backing store write option.

All entities and handles need to be preloaded using the CDD options for preload.

The following configuration in CDD should be enabled:

  • Object Management[Cache]/Domain Objects/Default/Cache Only
  • Object Management[Cache]/Domain Objects/Default/Preload Entities
  • Object Management[Cache]/Domain Objects/Default/Preload Handles

You can checkpoint individual tasks to provide more points of recovery. Checkpointing impacts performance due to the time it takes to persist the data. You should checkpoint only important tasks whose state must be persisted in the event of a shutdown.

Values of system variables (such as id, _extid, and messageid) are persisted, as well as the values of user variables (those you add to a project). Stale checkpoint values are automatically replaced by fresh ones as a process instance executes, so that the latest checkpointed states are used during recovery.

In case there are two process agents (with different priorities) and the Max Active field in the CDD file is set to the value “1”, the Process Orchestration software still performs the checkpointing and recovery automatically. If the process agent with the high priority is killed and process is still incomplete, the second process agent, with the low priority, becomes active and performs the recovery. The second process agent continues to execute the remaining process. Later when the high priority process agent starts again, it becomes active again and the second process agent, with low priority becomes inactive.

Checkpointing can be implicit or explicit.

Explicit Checkpoints

Explicit checkpoints are done when the user configures it at individual tasks. You can enable a checkpoint explicitly for the following tasks:

  • Script task
  • Business Rule
  • Send Message
  • Web Service
  • Inference task

Implicit Checkpoints

The BusinessEvents engine creates the checkpoints for the job definitions using version. Additionally, job instance states are checkpointed at the following points of execution:

  • Parallel Gateway - At gateways, checkpoints are made:
    • After all forks
    • Before all merges
  • Receive task
  • Call Activity task
  • Subprocess task.

Recovery

When an engine restarts, only jobs that were active at the time of the shutdown are recovered. They are loaded from the backing store into memory.

Jobs that were passive during a shutdown remain in the backing store until activated, for example by a message arriving at an intermediate event, or on activation by a timer event.