Ensuring ACID Semantics

As a relational database, TimesTen is ACID compliant.

Atomic: All TimesTen transactions are atomic: Either all database operations in a single transaction occur or none of them occur.
Consistent: Any transaction can bring the database from one consistent state to another.
Isolated: Transactions can be isolated. TimesTen has two isolation levels: read committed and serializable, which together with row level locking provide multi-user concurrency control.
Durable: Once a transaction has been committed, it remains committed.

The following sections detail how TimesTen ensures ACID semantics for transactions:

Locking and transaction logs are used to ensure ACID semantics as a transaction modifies data in a database.

Locking: TimesTen acquires locks on data items that the transaction writes and, depending on the transaction isolation level, data items that the transaction reads. See Concurrency Control Through Isolation and Locking.
Transaction logging: All TimesTen transactions are atomic. Either all or none of the effects of the transaction are applied to the database. Modifications to the database are recorded in a transaction log. Atomicity is implemented by using the transaction log to undo the effects of a transaction if it is rolled back. Rollback can be caused explicitly by the application or during database recovery because the transaction was not committed at the time of failure. See Transaction Logging.

The following table shows how TimesTen uses locks and transaction logs:

If	Then
Transaction is terminated successfully (committed)	Transaction log is written to the file system (depending on durability connection attribute). See Transaction Consistency and Durability. Locks that were acquired on behalf of the transaction are released and the corresponding data becomes available to other transactions to read and modify. All open result sets in the transaction are automatically closed.
Transaction is rolled back	Transaction log is used to undo the effects of the transaction and to restore any modified data items to the state they were before the transaction began. Locks that were acquired on behalf of the transaction are released. All open result sets in the transaction are automatically closed.
System fails (data not committed)	On first connect, TimesTen automatically performs database recovery by reading the latest checkpoint image and applying the transaction log to restore the database to its most recent transactionally consistent state. See Checkpoint Operations.
Application fails	All outstanding transactions are rolled back.

TimesTen provides consistency and durability with a combination of checkpointing and transaction logging.

A checkpoint operation writes the current in-memory database image to a checkpoint file on the file system.
- For TimesTen Classic, a successful checkpoint operation makes all transactions that have been committed at the time of the checkpoint operation consistent and durable.
- In TimesTen Scaleout, the data in your database is distributed across elements. Each element keeps its own checkpoint and transaction log files. As a result, the data stored in each element is independently durable.
  
  Each data instance in a grid manages one element of a database. In the event of a failure, a data instance can automatically recover the data stored in its element from the checkpoint and transaction logs files while the remaining data instances continue to service applications. If the K-safety value is 2 or greater, then a failed element can be recovered from another element in its replica set.
All transactions are logged to an in-memory transaction log buffer, which is written to the file system either with durable or nondurable transactions. See Durability Options.

Note:

Checkpointing and logging are further described in Checkpoint Operations and Transaction Logging.