Introduction to Transactions

Introduction to Transactions

A transaction is a logical unit of work that contains one or more SQL statements. A transaction is an atomic unit. The effects of all the SQL statements in a transaction can be either all committed (applied to the database) or all rolled back (undone from the database).

A transaction begins with the first executable SQL statement. A transaction ends when it is committed or rolled back, either explicitly with a COMMIT or ROLLBACK statement or implicitly when a DDL statement is issued.

To illustrate the concept of a transaction, consider a banking database. When a bank customer transfers money from a savings account to a checking account, the transaction can consist of three separate operations:

Oracle must allow for two situations. If all three SQL statements can be performed to maintain the accounts in proper balance, the effects of the transaction can be applied to the database. However, if a problem such as insufficient funds, invalid account number, or a hardware failure prevents one or two of the statements in the transaction from completing, the entire transaction must be rolled back so that the balance of all accounts is correct.

Figure 16–1 illustrates the banking transaction example.

16-2 Oracle9i Database Concepts

Introduction to Transactions

Figure 16–1 A Banking Transaction

Transaction Begins

Decrement Savings Account

UPDATE savings_accounts

SET balance = balance - 500

WHERE account = 3209;

Increment Checking Account

UPDATE checking_accounts

SET balance = balance + 500

WHERE account = 3208;

Record in Transaction Journal

INSERT INTO journal VALUES (journal_seq.NEXTVAL, '1B' 3209, 3208, 500);

End Transaction

COMMIT WORK;

Transaction Ends

Statement Execution and Transaction Control

A SQL statement that runs successfully is different from a committed transaction. Executing successfully means that a single statement was:

Parsed

Found to be a valid SQL construction

Run without error as an atomic unit. For example, all rows of a multirow update are changed.

However, until the transaction that contains the statement is committed, the transaction can be rolled back, and all of the changes of the statement can be undone. A statement, rather than a transaction, runs successfully.

Transaction Management 16-3

Introduction to Transactions

Committing means that a user has explicitly or implicitly requested that the changes in the transaction be made permanent. An explicit request means that the user issued a COMMIT statement. An implicit request can be made through normal termination of an application or in data definition language, for example. The changes made by the SQL statements of your transaction become permanent and visible to other users only after your transaction has been committed. Only other users’ transactions that started after yours will see the committed changes.

You can name a transaction using the SET TRANSACTION ... NAME statement before you start the transaction. This makes it easier to monitor long-running transactions and to resolve in-doubt distributed transactions.

See Also: "Transaction Naming" on page 16-9

Statement-Level Rollback

If at any time during execution a SQL statement causes an error, all effects of the statement are rolled back. The effect of the rollback is as if that statement had never been run. This operation is a statement-level rollback.

Errors discovered during SQL statement execution cause statement-level rollbacks. An example of such an error is attempting to insert a duplicate value in a primary key. Single SQL statements involved in a deadlock (competition for the same data) can also cause a statement-level rollback. Errors discovered during SQL statement parsing, such as a syntax error, have not yet been run, so they do not cause a statement-level rollback.

A SQL statement that fails causes the loss only of any work it would have performed itself. It does not cause the loss of any work that preceded it in the current transaction. If the statement is a DDL statement, then the implicit commit that immediately preceded it is not undone.

The user can also request a statement-level rollback by issuing a ROLLBACK statement.

Note: Users cannot directly refer to implicit savepoints in rollback statements.

See Also: "Deadlocks" on page 20-19

16-4 Oracle9i Database Concepts