1. On transactions, and Atomic Operations
Gail Shaw
Entelect

2. 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.

3. 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.

4. 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.

5. 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

6. 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!

7. Demo

8. 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

9. Demo

10. 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

11. Demo

12. 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

13. 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

14. 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

15. Demo

16. 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

17. 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

18. Resources Mini log series on transactions Concurrency is hard
(first in series)
Concurrency is hard