Upload
christian-allen
View
215
Download
0
Embed Size (px)
Citation preview
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)