Use Durable Commits Appropriately
Non-durable commits do everything that a durable commit does except write the transaction log to the file system. Locks are released and cursors are closed, but no file system write operation is performed.
Note:
Some drivers only write data into cache memory or write to the file system some time after the operating system receives the write completion notice. In these cases, a power failure may cause some information that you thought was durably committed to be lost. To avoid this loss of data, configure your file system to write to the recording media before reporting completion or use an uninterruptible power supply.
The advantage of non-durable commits is a potential reduction in response time and increase in throughput. The disadvantage is that some transactions may be lost in the event of system failure. An application can force the transaction log to be persisted to the file system by performing an occasional durable commit or checkpoint, thereby decreasing the amount of potentially lost data. In addition, TimesTen itself periodically flushes the transaction log to the file system when internal buffers fill up, limiting the amount of data that could be lost.
Transactions can be made durable or can be made nondurable on a connection-by-connection basis. Applications can force a durable commit of a specific transaction by calling the ttDurableCommit procedure.
Applications that use durable commits can benefit from using synchronous writes in
place of write and flush. To turn on synchronous writes set the first connection
attribute LogFlushMethod=1. The LogFlushMethod
attribute controls how TimesTen writes and synchronizes data to transaction log files.
Although application performance can be affected by this attribute, transaction
durability is not affected. See LogFlushMethod in the Oracle TimesTen In-Memory Database
Reference.
The txn.commits.durable column of the SYS.SYSTEMSTATS table indicates the number of transactions that were durably committed.