On transactions, and Atomic Operations Gail Shaw Entelect

Transactions The boundary of a unit of work A transaction completes entirely, or not at all A transaction can be committed, made part of the permanent database state, or rolled back, undone and leaving the database as if it had never run.

Transactional Properties A unit of work must exhibit four properties to be considered a transaction Atomicity (A) Consistency (C) Isolation (I) Durability (D) Together these are referred to as ACID Atomicity A transaction must be an atomic unit of work; either all of its data modifications are performed, or none of them is performed. Consistency When completed, a transaction must leave all data in a consistent state. In a relational database, all rules must be applied to the transaction's modifications to maintain all data integrity. All internal data structures, such as B-tree indexes or doubly-linked lists, must be correct at the end of the transaction. Isolation Modifications made by concurrent transactions must be isolated from the modifications made by any other concurrent transactions. A transaction either recognizes data in the state it was in before another concurrent transaction modified it, or it recognizes the data after the second transaction has completed, but it does not recognize an intermediate state. This is referred to as serializability because it results in the ability to reload the starting data and replay a series of transactions to end up with the data in the same state it was in after the original transactions were performed. Durability After a transaction has completed, its effects are permanently in place in the system. The modifications persist even in the event of a system failure.

Transactional Types In SQL Server, transactions have three forms Auto-commit. Default mode. Every statement is an individual transaction Implicit Transactions. First statement starts a transaction, has to be explicitly committed Explicit Transactions. Start a transaction with BEGIN TRANSACTION, has to be explicitly committed.

Transaction Guarantees If the COMMIT is run, all changes made within the transaction are fully durable i.e. part of the persistent database state If the connection terminates without the COMMIT having run, the transaction is rolled back All changes made within the transaction are undone If SQL Server restarts, upon restart it will undo all data modifications which were part of transactions that did not commit

Nested transactions If transactions are nested, only the outer-most BEGIN TRANSACTION actually starts a transaction Subsequent ones just increment a counter Only the final commit actually commits the transaction The earlier ones just decrement a counter A single rollback anywhere, however, rolls back everything Nested transactions are a lie!

Demo

Transactions and Locking Locks taken by a data modification are held until the end of the transaction In the default isolation level, shared locks are released at the end of the statement Need REPEATABLE READ isolation level for shared locks to be held until the end of the transaction There is nothing about a transaction which prevents other people from reading what you are reading Beware of the read and then update pattern

Demo

Transactions and Errors From the earlier discussion, it would be easy to conclude that errors encountered during a transaction cause a rollback. Books Online seems to imply that as well. However that is not the case

Demo

Transactions and Errors When wrapping multiple data modifications within a transaction for atomicity, error handling is essential Two ways of doing it Automatic, let SQL handle things Manual, explicitly defining what happens when there’s an error

Automatic error handling Controlled by the XACT_ABORT setting If that setting is on, any error which occurs within a transaction will result in the transaction being rolled back Still needs to be some error handling, but that can be in the calling app

Manual error handling TRY … CATCH blocks Any error which occurs in the TRY block causes the execution to be transferred to the CATCH block In the CATCH block, the error can be checked and either the transaction retried or rolled back. Can also re-throw the error for the application, or log it

Demo

Caveats, exceptions and special cases There are some database operations which do not roll back. Page splits, identity column increments, sequence increments Table variables do not participate in user transactions The DELAYED DURABILITY database option on SQL Server 2014 allows for committed transactions to be lost on a restart There are some errors which DO automatically roll back transactions, most DDL-related errors

In Conclusion Transactions provide a way for a number of data modifications be treated as a single atomic operation A transaction is automatically rolled back if the connection is terminated before it completes Errors do not cause a transaction to roll back by default Can be set to happen Can do manual error handling

Resources Demos on Github Mini blog series on transactions https://github.com/GilaMonsterZA/Demos Mini blog series on transactions http://sqlinthewild.co.za/index.php/2015/11/03/a-mess-of-nested-transactions/ (first in series) Concurrency is hard http://source.entelect.co.za/why-is-this-upsert-code-broken

Thank you Sponsors!