SQL-Transaction Statements control transactions in database access. This subset
of SQL is also called the Data Control Language for SQL (SQL DCL).
A D V E R T I S E M E N T
There are 2 SQL-Transaction Statements:
- COMMIT Statement
-- commit (make persistent) all changes for the current transaction
- ROLLBACK Statement
-- roll back (rescind) all changes for the current transaction
A database transaction is a larger unit that frames multiple SQL statements. A
transaction ensures that the action of the framed statements is atomic
with respect to recovery.
A SQL Modification Statement has limited effect. A given statement can only
directly modify the contents of a single table (Referential
Integrity effects may cause indirect modification of other tables.) The
upshot is that operations which require modification of several tables must
involve multiple modification statements. A classic example is a bank operation
that transfers funds from one type of account to another, requiring updates to 2
tables. Transactions provide a way to group these multiple statements in one
In SQL92, there is no BEGIN TRANSACTION statement. A transaction begins with
the execution of a SQL-Data statement when there is no current transaction. All
subsequent SQL-Data statements until COMMIT or ROLLBACK become part of the
transaction. Execution of a
COMMIT Statement or
ROLLBACK Statement completes the current transaction. A subsequent SQL-Data
statement starts a new transaction.
In terms of direct effect on the database, it is the
SQL Modification Statements
that are the main consideration since they change data. The total set of changes
to the database by the modification statements in a transaction are treated as
an atomic unit through the actions of the transaction. The set of changes
- Is made fully persistent in the database through the action of the
COMMIT Statement, or
- Has no persistent effect whatever on the database, through:
- the action of the ROLLBACK Statement,
- abnormal termination of the client requesting the transaction, or
- abnormal termination of the transaction by the DBMS. This may be an
action by the system (deadlock resolution) or by an administrative
agent, or it may be an abnormal termination of the DBMS itself. In the
latter case, the DBMS must roll back any active transactions during
The DBMS must ensure that the effect of a transaction is not partial. All
changes in a transaction must be made persistent, or no changes from the
transaction must be made persistent.
In most cases, transactions are executed under a client connection to the DBMS.
Multiple client connections can initiate transactions at the same time. This is
known as concurrent transactions.
In the relational model, each transaction is completely isolated from other
active transactions. After initiation, a transaction can only see changes to the
database made by transactions committed prior to starting the new
transaction. Changes made by concurrent transactions are not seen by SQL DML
query and modification statements. This is known as full isolation or
SQL92 defines Serializable for transactions. However, fully serialized
transactions can impact performance. For this reason, SQL92 allows additional
isolation modes that reduce the isolation between concurrent transactions. SQL92
defines 3 other isolation modes, but support by existing DBMSs is often
incomplete and doesn't always match the SQL92 modes. Check the documentation of
your DBMS for more details.
Transaction isolation controls the visibility of changes between transactions
in different sessions (connections). It determines if queries in one session can
see changes made by a transaction in another session. There are 4 levels of
transaction isolation. The level providing the greatest isolation from other
transactions is Serializable.
At transaction isolation level Serializable, a transaction is fully
isolated from changes made by other sessions. Queries issued under Serializable
transactions cannot see any subsequent changes, committed or not, from other
transactions. The effect is the same as if transactions were serial, that
is, each transaction completing before another one is begun.
At the opposite end of the spectrum is Read Uncommitted. It is the
lowest level of isolation. With Read Uncommitted, a session can read
(query) subsequent changes made by other sessions, either committed or
uncommitted. Read uncommitted transactions have the following characteristics:
- Dirty Read -- a session can read rows changed by transactions in
other sessions that have not been committed. If the other session then rolls
back its transaction, subsequent reads of the same rows will find column
values returned to previous values, deleted rows reappearing and rows
inserted by the other transaction missing.
- Non-repeatable Read -- a session can read a row in a transaction.
Another session then changes the row (UPDATE or DELETE) and commits its
transaction. If the first session subsequently re-reads the row in the same
transaction, it will see the change.
- Phantoms -- a session can read a set of rows in a transaction
that satisfies a search condition (which might be all rows). Another session
then generates a row (INSERT) that satisfies the search condition and
commits its transaction. If the first session subsequently repeats the
search in the same transaction, it will see the new row.
The other transaction levels -- Read Committed, Repeatable Read and
Serializable, will not read uncommitted changes. Dirty reads are not possible.
The next level above Read Uncommitted is Read Committed, and the
next above that is Repeatable Read.
In Read Committed isolation level, Dirty Reads are not possible, but
Non-repeatable Reads and Phantoms are possible. In Repeatable Read
isolation level, Dirty Reads and Non-repeatable Reads are not possible but
Phantoms are. In Serializable, Dirty Reads, Non-repeatable Reads, and
Phantoms are not possible.
The isolation provided by each transaction isolation level is summarized
Note: SQL92 defines the SET TRANSACTION statement to set the transaction
isolation level for a session, but most DBMSs support a function/method in the
Client API as an alternative.
SQL-Schema Statements in Transactions
The 3rd type of SQL Statements -
SQL-Schema Statements, may participate in the transaction mechanism.
SQL-Schema statements can either be:
- included in a transaction along with SQL-Data statements,
- required to be in separate transactions, or
- ignored by the transaction mechanism (can't be rolled back).
SQL92 leaves the choice up to the individual DBMS. It is implementation
The COMMIT Statement terminates the current transaction and makes all changes
under the transaction persistent. It commits the changes to the database.
The COMMIT statement has the following general format:
WORK is an optional keyword that does not change the semantics of COMMIT.
The ROLLBACK Statement terminates the current transaction and rescinds all
changes made under the transaction. It rolls back the changes to the
database. The ROLLBACK statement has the following general format:
WORK is an optional keyword that does not change the semantics of ROLLBACK.