Transaction Reclaim Operations

After a transaction is marked by TimesTen as committed, there is a reclaim phase of the commit.

About Reclaim Operations

TimesTen resource cleanup occurs during the reclaim phase of a transaction commit. Consider a transaction with DELETE operations.

For example. The SQL operation marks the deleted rows as deleted, but the space occupied by these rows are not actually freed until the reclaim phase of the transaction commit.

During reclaim, TimesTen reexamines all the transaction log records starting from the beginning of the transaction to determine the reclaim operations that must be performed, then performs those operations.

To improve performance, a number of transaction log records can be cached to reduce the need to access the transaction log files. This cache is referred to as the commit buffer and its size is configurable, as described in the next section, Configuring the Commit Buffer for Reclaim Operations.

Note:

The reclaim phase occurs as part of commit processing. Thus, once the reclaim phase has begun, the transaction is considered to be committed and can no longer be rolled back.
If an application is terminated during the reclaim phase, the cleanup operation completes the reclaim.

Configuring the Commit Buffer for Reclaim Operations

The reclaim phase of a large transaction commit results in a large amount of processing and is very resource intensive. For this reason, smaller transactions are generally recommended.

You can improve performance, however, by increasing the maximum size of the commit buffer, which is the cache of transaction log records used during reclaim operations.

Note:

It is not recommended that you perform an extremely large transaction commit (such as 1 million rows) as it is very resource intensive. In case that you are committing an extremely large transaction, do not cancel this transaction as it could cause the transaction to take even longer to complete. This is due to the fact that if you cancel a transaction while it has not completed, TimesTen has to perform rollback operations.

You can use the TimesTen CommitBufferSizeMax connection attribute to specify the maximum size of the commit buffer, in megabytes. This setting has the scope of your current session. For efficiency, initial memory allocation will be significantly less than the maximum, but will automatically increase as needed in order to fit all the relevant log records into the commit buffer, until the allocation reaches the maximum. The allocation is then reduced back to the initial allocation after each reclaim phase. By default, the maximum is 128 KB with an initial allocation of 16 KB. See CommitBufferSizeMax in Oracle TimesTen In-Memory Database Reference

Be aware that an increase in the maximum size of the commit buffer may result in a corresponding increase in temporary space consumption. There is no particular limit to the maximum size you can specify, aside from the maximum value of an integer, but exceeding the available temporary space will result in an error.

Note the following related features:

During the course of a session, you can use ALTER SESSION to change the maximum size of the commit buffer as follows, where n is the desired maximum, in megabytes. See ALTER SESSION in Oracle TimesTen In-Memory Database SQL Reference.
```
ALTER SESSION SET COMMIT_BUFFER_SIZE_MAX = n
```
You can use the ttCommitBufferStats built-in procedure to gather statistics for your connection to help you tune the commit buffer maximum size. This built-in takes no parameters and returns the total number of commit buffer overflows and the highest amount of memory used by reclaim operations for transaction log records, in bytes. If there are buffer overflows, you may consider increasing the commit buffer maximum size. If there are no overflows and the highest amount of memory usage is well under the commit buffer maximum size, you may consider decreasing the maximum size.

In TimesTen Classic, you can use the ttCommitBufferStatsReset built-in procedure to reset these statistics to 0 (zero). This is useful, for example, if you have set a new value for the commit buffer maximum size and want to restart the statistics.

See ttCommitBufferStats and ttCommitBufferStatsReset in Oracle TimesTen In-Memory Database Reference.
The system-wide number of commit buffer overflows is also recorded in the TimesTen statistic txn.commits.buf.overflowed in the SYS.SYSTEMSTATS table. See SYS.SYSTEMSTATS in Oracle TimesTen In-Memory Database System Tables and Views Reference.
You can check the current setting of CommitBufferSizeMax by calling the ttConfiguration built-in procedure.