8.6 Transaktioner1 Transaktioner 8.6 Transactions in SQL

8.6 Transaktioner2 Transaktion En transaktion er en enhed for logisk arbejde på en database. Eksempler: –flyt penge fra en konto til en anden –reserver et fly-sæde Defineres af database-brugeren / applikations-programmøren

8.6 Transaktioner3 Seriel afvikling, 397 Simpel model: Transaktioner foregår serielt –først transaktion, så din transaktion, osv. –ingen ser inkonsistente mellemresultater flyt 100 kr. fra konto 145 til konto 111 –update konto set saldo = saldo where kontonr = 145; »inkonsistent mellemresultat - skal ikke ses af andre –update konto set saldo = saldo where kontonr = 111;

8.6 Transaktioner4 Serialisering, 397 Den simple model holder ikke –Der foregår meget samtidigt transaktioner på en stor database (f.eks. Danske Bank, SAS) –Eksempel: 2 personer booker samme fly-sæde, fig. 8.23, side 399 Serialisering –Resultatet af mængde transaktioner databasen skal have samme resultat som en seriel afvikling af transaktionerne. –Serialisering kræver ikke seriel afvikling! –DBMS sørger for serialisering ofte ved at låse data, så de midlertidigt ikke kan bruges af andre transaktioner.

8.6 Transaktioner5 Udelelighed, 399 En transaktion skal være udelelig –Enten finder den sted i sin fulde udstrækning eller også finder den slet ikke sted. –Ingen halve transaktioner Transaktionen må altså ikke stoppe midt i penge- overførelsen - uanset om DBMS'en går ned! –Overholdes af DBMS'en.

8.6 Transaktioner6 Transaktioner start og afslutning, 402 En transaktion starter med første SQL- sætning. Transaktion slutter med –commitalt er godt data kan gøres synlige for andre transaktioner –rollbacknoget gik galt (f.eks. overtræk) databasens tilstand skal være som før transaktionen startede (klares af DBMS'en)

8.6 Transaktioner7 Transaktioners egenskaber, ACID Atomicity –En transaktion udføres udeleligt. Udføres af DBMS Consistency –En transaktion fører databasen fra en konsistent tilstand til en anden måske med inkonsistente mellem-tilstande Defineres af database anvender / applikations-programmør Isolation –En transaktion er isoleret fra andre transaktioner Udføres af DBMS, concurrency control Durability –Resultat af en committed transaktion kan aldrig forsvinde. Heller ikke selv om DBMS crasher DBMS sørger for recovery.

8.6 Transaktioner8 Transaktioner i JDBC interface java.sql.Connection –void setAutoCommit(boolean autoCommit) pr. default er autoCommit = true, dvs. enhver SQL-sætning er sin egen lille transaktion. –void commit() –void rollback() –eksempel JdbcTransactionExample.java Ingen eksplicit start på en transaktion –første SQL-statement efter commit / rollback er starten på en ny transaktion. Transaktioner skal afsluttes før connection.close()

8.6 Transaktioner9 Read-only transaktioner, 403 Read-only transaktioner er ikke så "farlige" som read-write transaktioner –Der er aldrig sket noget ved at læse Starten på en read-only transaktion kan markeres, så DBMS'en ved det JDBC –ingen metoder til at markere en transaktioner som read-only!

8.6 Transaktioner10 Dirty reads, 405 Dirty data –Data, der er opdateret af en transaktion, som endnu ikke er committed. Dirty read –En transaktion, der læser dirty data. Et problem, hvis den "dirty" transaktion senere laver rollback. –Dirty reads vs. "omkostninger" DBMS skal checke om dirty reads kan opstå. Mindre concurrency i afviklingen af transaktioner. –Nogle gange er dirty reads et stort problem Eksempel 8.30, side 405 –Andre gang er dirty reads ikke noget stort problem Eksempel 8.31, side 406

8.6 Transaktioner11 Isolation levels, 407 Database-anvender / applikations-programmør kan selv bestemme om en transaktion må lave dirty read –OBS ikke det samme som at andre transaktioner ikke må lave dirty read på den aktuelle transaktion. –2 isolation levels serializablemå kun læse fra committed transaktioner read uncommitteddirty reads er OK –JDBC java.sql.Connection void setTransactionIsolation(int level) static final int TRANSACTION_SERIALIZABLE static final int TRANSACTION_READ_UNCOMMITTED –Der findes yderligere 2 isolation levels