ttCkptBlocking

Description

Implements a blocking checkpoint. A checkpoint operation is used to make a record of the current state of the data store on disk, and to purge transaction log files. This checkpoint requires exclusive access to the data store, and so may cause other applications to be blocked from the data store while the checkpoint is in progress.

When this procedure is called, TimesTen performs a blocking checkpoint when the current transaction is committed or rolled back. If, at that time, other transactions are in progress, the checkpointing connection waits until the other transactions have committed or rolled back. While the checkpoint connection is waiting, any other new transactions that want to start form a queue behind the checkpointing transaction. As a result, if any transaction is long-running, it may cause many other transactions to be held up. So this blocking checkpoint should be used with caution. To perform a non-blocking checkpoint, use the ttCkpt procedure.

No log is needed to recover when blocking checkpoints are used. TimesTen uses the log, if present, to bring the data store up to date after recovery.

Required privilege

This procedure requires the ADMIN privilege.

Syntax

ttCkptBlocking(timeout, retries)

Parameters

ttCkptBlocking has these optional parameters:

Parameter	Type	Description
`timeout`	TT_INTEGER	The time (in seconds) that ttCkptBlocking should wait to get a data store lock before timing out. The value of `timeout` can be between 0 and one million, inclusively. If not specified, it defaults to infinity (the checkpoint never times out).
`retries`	TT_INTEGER	The number of times that ttCkptBlocking should attempt to get a data store lock, if timeouts occur. The value of `retries` can be between 0 and 10, inclusive. If not specified, defaults to zero.

Result set

ttCkptBlocking returns no results.

Example

CALL ttCkptBlocking();
CALL ttCkptBlocking(1,10);

Notes

Because the checkpoint takes place at commit or rollback, the call to ttCkptBlocking always succeed. At commit or rollback, any problems with the checkpoint operation, such as a lack of disk space or a timeout, result in a warning being returned to the application. Checkpoint problems are not reflected as errors, since the commit or rollback of which they are a part can succeed even if the checkpoint fails. Warnings are reflected in ODBC with the return code SQL_SUCCESS_WITH_INFO.

For more information on checkpoints, see "Transaction Management and Recovery" in Oracle TimesTen In-Memory Database Operations Guide.