1. Transactions1 Unit of work on a database

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

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

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

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

6. Transactions6 Transactions, ”boundaries” Start transaction –Not stated explicitly –The first SQL statement starts the transaction End transaction, 2 possibilities –Commiteverything is OK Transaction ended successfully –Rollbacksomething is wrong (overdraft?) Database state rolled back to the state before the transaction started [as if the transaction never happened]

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

8. Transactions8 Transaction, example Transferring money –Update accounts set balance = balance – 100 where number = 14593; –Update accounts set balance = balance + 100 where number = 12345; –Commit;

9. Transactions9 JDBC, Java API Interface java.sql.Connection –void setAutoCommit(boolean autoCommit) Default: true, every SQL statement is a small transaction –void commit() –void rollback()

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

11. Transactions11 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

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

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

14. Transactions14 Dirty reads, examples Transfer money add money to account A if (account B has enough money) remove money from B commit else rollback Dirty read matters! Seat reservation clerk finds a seat and marks it as occupied. clerk asks customer for approval if (approved) commit else rollback Dirty read doesn't matter much.

15. Transactions15 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 serializabledirty reads not allowed read uncommitteddirty 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)