Non-Durable Transactions for TimesTen

Non-durable transactions run considerably faster than durable transactions. Connections that use non-durable transactions can coexist with connections that use guaranteed durability.

As with guaranteed durability, each transaction enters records into the in-memory transaction log buffer as it makes modifications to the database. However, when a transaction commits in non-durable mode, it does not wait for the transaction log buffer to be written to the file system before returning control to the application. Thus, unless you have configured asynchronous replication or an asynchronous writethrough cache group, a non-durable transaction may be lost in the event of a database failure. Eventually, transactions are flushed to the file system into the transaction log files by the database subdaemon process or when the in-memory transaction log buffer is full.

If your transactions require extremely high throughput with minimal exposure to data loss, then consider doing BOTH of these options:

  • Use one of these methods to perform an asynchronous write operation of your data to another database: a TimesTen database or an Oracle database.

    • Use the default asynchronous replication that replicates committed transactions from the master to the subscriber. With the default asynchronous replication, an application updates a master database and continues working without waiting for the updates to be received and applied by the subscribers. While asynchronous replication provides the best performance, it does not provide the application with confirmation that the replicated updates were committed on subscriber databases. See Copying Updates Between Databases Oracle TimesTen In-Memory Database Replication Guide.

    • Set up an Asynchronous WriteThrough (AWT) cache group to cause committed updates on TimesTen cache tables to be automatically and asynchronously propagated to the cached Oracle Database tables. A transaction commit operation on the TimesTen database occurs asynchronously from the commit on the Oracle database. This enables an application to continue issuing transactions on the TimesTen database without waiting for the Oracle Database transaction to complete. However, your application cannot ensure when the transactions are completed on the Oracle database. See Asynchronous WriteThrough (AWT) Cache Group in the Oracle TimesTen In-Memory Database Cache Guide.

  • Configure for non-durable transactions by setting the DurableCommits connection attribute to 0, which asynchronously writes non-durable commit log records to the transaction log file.

    See DurableCommits in the Oracle TimesTen In-Memory Database Reference.

The only transactions vulnerable to loss in the event of a system failure are those that committed non-durably after the last durable commit and were not replicated prior to the failure.

However, if you have critical transactions that cannot be exposed to any data loss, you can either:

  • Replicate those transactions synchronously from the master database to the subscriber database by running the ttRepSubscriberWait built-in procedure.

    Running the ttRepSubscriberWait built-in procedure on the master database using the DSN and host of the subscriber database causes the caller to wait until all transactions that committed before the call have been transmitted to the subscriber. See ttRepSubscriberWait in the Oracle TimesTen In-Memory Database Reference.

  • Force the individual transactions to commit durably to the transaction log files with the ttDurableCommit built-in procedure. Committing a transaction durably makes that transaction and all previous transactions durable. However, this does not wait for the transaction to be replicated.

    When a durable commit is needed, the application can call the ttDurableCommit built-in procedure before committing. The ttDurableCommit built-in procedure does not actually commit the transaction; it merely causes the commit to be durable when it occurs.

    This maintains a smaller window of vulnerability to transaction loss as opposed to all transactions being committed non-durably. By committing only every nth transaction durably or performing a durable commit every n seconds, an application can achieve a quicker response time while maintaining a small window of vulnerability to transaction loss. A user can elect to perform a durable commit of a critical transaction, such as one that deals with financial exchange, that cannot be vulnerable to loss.

    See ttDurableCommit in the Oracle TimesTen In-Memory Database Reference.