Transactions 1

Transactions

Unit of work on a database

Transactions 2

Transactions, concept

• Logical unit of work on the database– Examples

• Transfer money from bank account A to bank account B

• Reserve a seat on a flight

– Defined by the DBMS user / application programmer

Transactions 3

Serial schedule

• Simple model: Transactions executed in a serial schedule– first my transaction, then your transaction, etc.– other transactions should not see preliminary

results• update account set balance = balance - 100 where

number = 14593;– preliminary result - invisible to other transactions

• update account set balance = balance + 100 where number = 12345;

Transactions 4

Serializable schedule

• The simple model (serial schedules) doesn't work– Many simultaneous transactions on a database (e.g.

huge banking company, or ticket reservation)• Serializable schedule

– The outcome of the transaction must be equivalent to some serial execution of the transactions.

– Serializable transactions doesn't require serial execution!

– The DBMS guarantees serializability.• often by locking data, preventing other transaction from

accessing the data

Transactions 5

Atomicity

• A transaction must be indivisible– Either it's fully execute, or it's not executed at

all– No half done transactions!

• Money transfer cannot stop after on account is updates.

– Enforced by the DBMS.

Transactions 6

Transactions, ”boundaries”

• Start transaction– Not stated explicitly

– The first SQL statement starts the transaction

• End transaction, 2 possibilities– Commit everything is OK

• Transaction ended successfully

– Rollback something is wrong (overdraft?)• Database state rolled back to the state before the transaction

started [as if the transaction never happened]

Transactions 7

Transaction characteristics, ACID• Atomicity

– A transaction is either fully executed or not• Enforced by the DBMS: Transactions

• Consistency– A transactions takes the database from one consistent state to

another• With possible inconsistent states in between.• Defined by the database user / application programmer.

• Isolation– The results of a transaction must be invisible to other transactions

– until the transactions has ended.• Enforced by the DBMS: Transactions

• Durability– The results of a finished transactions must never disappear

• Not even if the DBMS crashes• Enforced by the DBMS: Recovery

Transactions 8

Transaction, example

• Transferring money– Update accounts set balance = balance – 100

where number = 14593;– Update accounts set balance = balance + 100

where number = 12345;– Commit;

Transactions 9

JDBC, Java API• Interface java.sql.Connection

– void setAutoCommit(boolean autoCommit) • Default: true, every SQL statement is a

small transaction

– void commit() – void rollback()

Transactions 10

Deferred constraints and commit

• Problem (chicken and egg)– 2 tables are mutually dependent

• table A has a foreign key referring to table B and vice versa.

• we cannot insert anything into the tables without referring to non-existing data

• Solution– Declare the foreign keys "deferred deferrable …"

• foreign constraint not checked before the transaction commits

• If constraints are not true, the transaction fails!!

Transactions 11

Save points• Ordinary rollback

– Roll the transaction back to the beginning

• Rollback to save point– Roll the transaction back to a point in the middle of the

transaction– Works with Oracle 9i

• JDBC (Java API) java.sql.Connection– Savepoint setSavepoint() JDK 1.4– Savepoint setSavepoint(String name) JDK 1.4– void rollback(Savepoint savepoint)

JDK 1.4– implemented in Oracle 9i JDBC

Transactions 12

Read only transactions• Read-only transactions are not as

"dangerous" as read-write transactions– Nothing ever happened from reading

• A read-only transaction should be marked as such when the transactions starts.– DBMS may run the read-only transaction in

parallel with other read-only transactions.

• JDBC– No support for read-only transactions.

Transactions 13

Dirty reads

• Dirty data– Data, updated by a transaction, not yet committed.

• Dirty read– A transaction reading dirty data.

• DBMS can prevent dirty reads– takes time– reduces concurrency

• Sometimes dirty reads matters, sometimes it doesn't.

Transactions 14

Dirty reads, examples

• Transfer moneyadd money to account A

if (account B has enough money)remove money from B

commit

elserollback

• Dirty read matters!

• Seat reservationclerk finds a seat and marks it as

occupied.

clerk asks customer for approval

if (approved)commit

elserollback

• Dirty read doesn't matter much.

Transactions 15

Isolation levels• Database user / application programmer can

decide if a transaction may do dirty reads– but not if other transactions may do dirty reads on "his"

transaction!– 2 isolation levels

• serializable dirty reads not allowed• read uncommitted dirty read allowed

– JDBC java.sql.Connection• void setTransactionIsolation(int level) • static final int TRANSACTION_SERIALIZABLE • static final int TRANSACTION_READ_UNCOMMITTED

– There are 2 more transaction levels (total of 4 levels)