Skip Headers
Oracle® TimesTen In-Memory Database Reference
Release 11.2.1

Part Number E13069-03
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF



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.


ttCkptBlocking(timeout, retries)


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.


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


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.

See also