Additional details related to transaction processing have been addressed in this release, including:
Global Transaction Number - The c-treeACE Server utilizes a “Global Transaction Number” value to determine the next transaction number when a new transaction is created. Transaction numbers are critical to the data integrity, and, among other areas, are persisted within our transaction logs. Legacy versions of the c-treeACE Server (V8.14 and prior) maintained a 4-byte global transaction number. Our current server maintains a 6-byte transaction number. If the number of transactions initiated for a database exceeds this 6-byte number, transaction log maintenance must be performed. This involves shutting down the server and executing a maintenance utility on the database files and logs. With a 6-byte number, a server can perform approximately 1000 transactions per second for 2000 years. That’s 70 TRILLION transactions, so typically this offline maintenance is never required. We have added the ability for the users to define within the server’s configuration file a “threshold warning” value. When the Global Transaction Number base reaches this value, the server will issue warnings. This user-defined value allows users who still have legacy data with 4-byte transactions numbers to set the “warning threshold” below the 4-byte limit, which is around 1 billion transactions, giving notification of the necessary maintenance.
Transactions with over 32768 SAVE POINTS - It may seem a little extensive to have this many save-points within a single transaction, yet c-treeACE developers are known for pushing the limits.
Overlapping checkpoints - During our performance profiling, we improved the synchronization of a user-invoked checkpoint with an internal checkpoint already in operations. If a checkpoint was forced from an application level CTCHKPNT() call, and an in-process checkpoint is already in progress, internal logic has been improved to avoid any additional processing overhead as a checkpoint is already in progress.
Deferred transaction file number assignment - An additional performance improvement has been implemented. We found that transaction file numbers could be deferred until the file was actually updated. Previously, when c-treeACE physically opened a transaction-controlled data or index file, it assigned a transaction file number to the file and wrote an entry to the transaction log. As a result, even if a file was simply opened, read, and then closed, the operations performed unnecessary log overhead. Now, c-treeACE defers the file number assignment and transaction logging until the first update is made to the file. This gives us performance gains for these “read-only” situations.
Excessive number of transaction logs - Under rare situations, the c-treeACE Server had been observed to retain an excessive number of transaction logs. While numerous logs are expected in normal processing under a large transaction loads, we have also determined that a situation may exist when a buffer page has not been flushed, causing the server to retain a hold on a log file when it does not need to do so. The c-treeACE Server now detects and corrects this situation during checkpoint processing.
