Transaction Atomicity, Consistency, and Isolation

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.