Changing the Checkpoint Data Repository for a Process

A checkpoint saves the current state of a running process instance. For a secondary process engine to resume running process instances from their last checkpoint, the secondary process engine must have access to the saved state of the process instances from the master process engine.

Features that allow communication across process engines (for example, wait/notify, critical sections, shared variables, and so on) require a database for storage of process engine state.

If you are running process engines that do not communicate with each other, then the file system can be used for process engine storage. In this case, if you configure primary and secondary engines for fault tolerance, all engines must point to the same shared location within the file system.

The remainder of this section describes using a database for process engine storage.

Because fault-tolerant engines are expected to be on separate machines, you should specify to use a database for storage for each process engine. This allows you to specify the same JDBC Connection resource for the master and secondary engines, and therefore all engines can share the information stored for process instance checkpoints.

If all engines share the checkpoint information, and then the secondary engines can recover process instances up to their last checkpoint. If engines do not share the checkpoint information, process instances are not restarted.

To change checkpoint data repository properties, perform the following procedure:

Procedure 

1. In TIBCO Administrator, click Application Management.
2. Select an application and expand it.
3. In the Configuration Builder pane, click a process name. A process is named with a .par suffix.
4. Click the Advanced tab.
5. Change properties as required. The value defaults to Checkpoint Data Repository. If the JDBC Connection Resource has been configured for the project, you also have the option to choose database.
6. Click Save.