Special Considerations

Checkpoint and Restore Operations and Joined Tables

You need to consider some issues when performing checkpoint or restore operations on parent tables or child tables. For a general description of Checkpoint and Restore operations, see Checkpoints of In-Memory Data.

There are links between parent and child tables, and between parent and child records. To maintain the consistency of these links, any checkpoint or restore operation must checkpoint or restore all of the linked tables as a unit in a single operation.

If they are not checkpointed or restored as a unit, it might cause inconsistencies such as:

•

Incorrect linking of a restored child table to an unintended parent table

•

Incorrect linking of a child record to a parent record

•

Failure in linking intended records

•

Failure in restoring a child table because the parent table does not exist

In some cases, error messages are displayed and corrections can be made. However, in some cases, incorrect linkages can be made with no errors being reported. Such quiet errors can result in propagating erroneous results. Such errors can be difficult to correct, once found. To avoid such scenarios, TIBCO Patterns server enforces some restrictions on checkpoint and restore operations on parent and child tables.

To help you understand the restrictions related to the checkpoint and restore operations, the term joined set of tables is used. A joined set of tables is a set consisting of a parent table and all the child tables linked to the parent table.

 

This restriction works differently for checkpoint operation and restores operation.

For checkpoint operations, if a table from a joined set of tables is included in the list of tables to the checkpoint, the entire joined set of tables is checkpointed.

For restore operations, it is required that all of the tables in the joined set of tables be explicitly listed. The server rejects any request that does not do so. Requiring all tables be explicitly listed in the restore request, instead of automatically completing a join set of tables, prevents inadvertently deleting existing in-memory tables.

For example, consider four tables:

—

Table A: a standard table

—

Table B: a parent table

—

Table C: a child table linked to table B

—

Table D: a child table linked to table B

If you request a checkpoint operation on Table A, only Table A is checkpointed. This is the standard operation. If you request a checkpoint operation on Table C, three tables, namely, Table B, Table C, and Table D, are checkpointed. This shows that if a request to checkpoint a single table from a joined set of tables is made, the TIBCO Patterns server checkpoints all tables in the joined set.

Consider the scenario where all the tables mentioned before are checkpointed.

1.

Shut down and restart the TIBCO Patterns server without auto-restore.

2.

Create a standard Table C.

3.

Issue a request to restore Table A and Table B.

4.

Assume the TIBCO Patterns server automatically restores all tables in a joined set, as it does for checkpoint operations. It then reloads Table B, Table C and Table D, destroying the Table C just created.

To avoid this possibility, the server restores only explicitly requested tables. It rejects requests that include an incomplete joined set of tables. In the prior example, the restore request is rejected in its entirety because the request for restoring Table B without Table C and Table D represent an incomplete joined set of tables. Unlike table not found errors, an incomplete joined set error causes the entire request to fail and none of the tables are restored.

This requirement for complete joined sets applies to both in-memory tables and the tables checkpointed to the disk. These are not necessarily the same and in some situations it can make it impossible to checkpoint or restore tables. Consider the following situation.

5.

Create four tables as in the previous example.

6.

Shut down and restart the TIBCO Patterns server without auto-restore.

7.

Create three new tables:

—

Table C: a parent table

—

Table B: a child table linked to Table C

—

Table E: a child table linked to Table C

8.

Try to checkpoint Table C, Table B, and Table E.

You can observe the following:

•

The checkpoint request fails as the checkpoint files on the disk contain a joined set of tables: Table C, Table D. The in-memory tables contain a joined set of tables, Table C, Table B, and Table E. The joined sets overlap but are not equal.

•

If Table C, Table B, and Table E are checkpointed, the joined set of tables on the disk is broken and the original tables, Table B and Table C are lost.

•

An attempt to restore Table B, Table C, and Table D results in destroying the in-memory Table C leaving Table E without a parent. So this is not allowed.

This situation can only occur when you start the server without selecting the auto-restore option (see the TIBCO Patterns Installation Guide for a description of the auto-restore option) and the checkpoint-restore directory contains existing checkpoint files.