1. Why should a database transaction be atomic?

2. ABORT = Removal of the updates of a transaction An abort is implemented by a roll back recovery where the before images of the log-file are restored in the database tables. What can initiate an automatic abort? When should a programmer initiate an abort?

3. The Relaxed Atomicity Property: Committing subtransaction Root transaction

4. Nested atomic subtransactions: Subtransactions of a compensatable subtransaction must also be compensatable. Subtransactions of a retriable subtransaction must also be retriable. Subtransactions of a pivot subtransaction must either be compensatable or retriable. Where would you recommend to use retriable sub-subtransactions in E-commerce?

5. The Relaxed Atomicity Property: Committing subtransaction Root transaction How would you implement relaxed atomicity in a real- time money transfer between two banks?

6. The Relaxed Atomicity Property: Committing subtransaction Root transaction In E-commerce the following locations are involved: Seller, Bank of Seller, Buyer, Bank of Buyer, and Card issuer. In which locations should the compensatable, pivot and retriable subtransactions be executed?

7. The Relaxed Atomicity Property: Committing subtransaction Root transaction How would you recommend to implement atomic data replication from a primary copy by using relaxed atomicity?

8. Types of Nested Transactions Closed nested Transaction (DDBMS transactions) –Sub-transaction begins after the root and finishes. –Commit of sub-transaction is conditional upon the commit of the root –Top-level atomicity Open Nested Transactions (Flexible transactions) –Relaxation of top-level atomicity –Partial results of sub-transactions visible Sagas Split transactions –Retriable subtransactions may occur

9. Advantages of Open Nested Transactions Higher level of concurrency –Objects can be released after sub-transaction execution Independent recovery of sub-transactions –Damage is limited to a smaller part, making it less costly to recover It is possible to create new transactions from existing ones

10. Implementation of retriable subtransactions: In practice SOA services function as RPCs and may also be used to implement UP.

11. Atomicity in mobile computing: How can SOA help in implementing mobile atomicity?

12. Isolation anomalies occurs when you brake locking rules: -----------------------------------------------

13. Example of Lost update anomaly: History: r1(x)…w2(x)…w1(x)…c1 How can the Lost Update be prevented?

14. The anomalies allowed by the different isolation levels of SQL Readlocks do not lock the index. Read does not exclude writes. (Only update locks exist). Update locks do not exclude reads.

15. SQL Isolation Levels Isolation levels determine what a transaction is allowed to see. The declaration, valid for one transaction, is: SET TRANSACTION ISOLATION LEVEL X ; where X = 1.SERIALIZABLE (the default value) 2.REPEATABLE READ 3.READ COMMITTED 4.READ UNCOMMITTED

16. The history of Lost update anomaly:

17. Examples of Lost update anomaly: r1(x)…w2(x)…w1(x)…c1 1.Is ”the lost update anomaly” acceptable when the address of a customer is changed? 2.Is ”the lost update anomaly” acceptable when the amount of available airplane tickets are reduced by B2C e-commerce? 3.Is ”the lost update anomaly” acceptable when the diagnose of a patient is changed? 4.Is the ”lost update anomaly” possible when the diagnose of a patient is created?

18. Isolation anomalies occurs when you brake locking rules: -----------------------------------------------

19. The history of Dirty read anomaly:

20. Examples of Dirty read anomaly: w1(x)…r2(x)…c2…a1... 1.Is the dirty read anomaly acceptable when the address of a customer is changed? 2.Is the dirty read anomaly acceptable when the amount of available airplane tickets are red by B2C e-commerce customer? 3.Is the dirty read anomaly acceptable when you want to read the diagnose of a patient? 4.Is the dirty read anomaly acceptable if you want to change the diagnose of a patient? 5.Is the dirty read anomaly acceptable when you have to decide whether to give a loan to a customer?

21. Isolation anomalies occurs when you brake locking rules: -----------------------------------------------

22. The history of Fuzzy read anomaly = Non-repeatable read anomaly:

23. Examples of Non-repeatable read anomaly: r1(x)…w2(x)… c2…r1(x)…. 1.Is the Non-repeatable read anomaly acceptable when the address of a customer is changed? 2.Is the Non-repeatable read anomaly acceptable when the amount of available airplane tickets are reduced by B2C e- commerce? 3.Is the Non-repeatable read anomaly acceptable when you want to read the diagnose of a patient? 4.Is the Non-repeatable read anomaly acceptable if you want to change the diagnose of a patient? 5.Is the Non-repeatable read anomaly acceptable when you have to decide whether to give a loan to a customer?

24. Isolation anomalies occurs when you brake locking rules: -----------------------------------------------

25. The history of Phantom anomaly:

26. Examples of Phantom anomaly: r1 (S)…w2(y now in S)…c2…r1 (S)… 1.Is the Phantom anomaly acceptable when the address of a customer is changed? 2.Is the Phantom anomaly acceptable when the amount of available airplane tickets are reduced by B2C e-commerce for one of the airline companies? 3.Is the Phantom anomaly acceptable when you want to read the health records of a patient? 4.Is the Phantom anomaly acceptable if you want to change the diagnoses of a patient? 5.Is the Phantom anomaly acceptable when you have to decide whether to give a loan to a customer?

27. More on SQL and Transactions If the transaction is only reading, we can allow more operations in parallel by using: EXEC SQL SET TRANSACTION READ ONLY; The default is: SET TRANSACTION READ WRITE;

28. End of session Thank you !!!

29. Anomalies between a record x and its replica y: The Read skew anomaly illustrates that that a shared lock (read lock) does not exclude writes globally: Read skew: r1(x)…w2(x)… w2(y)…c2… r1(y) …... The Write skew anomaly illustrates that that an exclusive lock (write lock) does not exclude writes globally: Write skew: r1(x)… r2(y)… w2(y)…w1(x)…c1…c2. The Asynchronous replication anomaly illustrates that that a exclusive lock (write lock) does not exclude reads globally: Asynchronous replication anomaly: w1(x).. r2(y)..c2..w1(y).. c1.

30. The general read skew anomaly: Read skew: r1(x)…w2(x)… w2(y)…c2… r1(y) …... The read skew anomaly is a situation where a first transaction reads a record. Next, a second transaction updates the record and a related record. The updates are committed. Finally, the first transaction reads the related record. In this situation, the first transaction may find that the integrity rules of the database have been violated by the changes made by the second transaction.

31. The general write skew anomaly: Write skew: r1(x)… r2(y)… w2(y)…w1(x)…c1…c2. The write skew anomaly is a situation where two transactions both read two different related records. Next, the two transactions each update one of the two related records. Finally, both transactions commit. If a constraint has existed between the two related records, it might have been violated.

32. Implementation of distributed CSCW: Describe compensatable, pivot, and retriable subtransactions for the most important update transactions Describe the countermeasures recommended for the most important transactions

33. Objectives for a DDBMS (Distributed DataBase Management System): Distribution transparency, that is Replication transparency Distributed optimizer Distributed ACID properties Homogeneity as Heterogeneity is not in the marked

34. Evaluation of distribution architectures Evaluation criteria Distribution architectures Synchronous distributed database management system (DDBMS) Central database with distributed clients Multidatabases with flexible transactions. (Relaxed ACID properties) Hot backup possibility n-safe and mirroringOnly mirroring is possible 0- safe, 1 safe and mirroring Read performance/ capacity BestWorstAverage Write performanceWorstAverageBest Blocking possibilityYesNono Ease of failure recovery Worst (The systems are very complex) Best Disaster recoveryBestWorstAverage The probability of lost data[1][1] Best. p n Worst p Average Transaction loggingNot supported Recommended Availability[2][2]1-q n 1-q1-q n AtomicityBest ConsistencyBest Worst IsolationBest Worst DurabilityBest Develop-ment costsBest Worst [1][1] The probability of lost data as a function of the probability, say p, of a local disaster. [2][2] The availability as a function of the probability, say q, of a local site failure.

35. Distributed DataBase Management System(DDBMS) TM = Transaction Manager. DM = Data Manager.

36. Distribueret data dictionary: Global user views Other locations Distribution schema Global conceptual view Fragmentation schema Allocation schema Server Local schema Other locations Local conver- sion schema Local schema Server

37. Distributed DataBase Management System(DDBMS) TM = Transaction Manager. DM = Data Manager.

38. Homogenious DDBMS. TM dictio- nary DM dictio- nary

39. Heterogenious DDBMS. TM dictio- nary Conver- sion schema

40. Commit by using distributed 2PC:

41. Abort with distributed 2PC