1. The ACID properties of transactions: Atomicity = the all or nothing update property. Consistency = if a database is consistent before a transaction is exected, then the database must alo be consistent after the transaction is executed. Isolation = The updates of a transaction must not be seen by other transactions before the transaction is committed. Durability = Committed data can be recovered in case of failures. -----------------------------------------------

2. DBMS Implementation of ACID Properties: Logging and Recovery: Guarantees Atomicity and Durability. Concurrency control: Guarantees Consistency and Isolation.

3. Two phase locking (2PL): All locks must be obtained in first phase of 2PL and released in second phase. Commit point Lock growing phase shrinking phase Time Number of locks Is it the same phases that are used in 2PL and 2PC?

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

5. Example of Lost Update anomaly: History: r1(x)…w2(x)…w1(x)…c1

6. The history of Lost update anomaly: How can the Lost Updates be prevented?

7. Countermeasures against isolation anomalies: The Reread Counter-measure The Commutative Updates Counter-measure The Version File Counter-measure The Version File combined with the Commutative Updates Counter-measure The Pessimistic View Counter-measure The Semantic Lock Counter-measure Counter-measures by Value The Timestamp Counter-measure The Re-timestamp Counter-measure The End of Day Transaction Countermeasure

8. Countermeasures against lost updates: r1(x)…w2(x)…w1(x)…c1 The Reread Counter-measure can prevent lost updates, dirty reads, non-repeatable reads, write skews and asynchronous replication anomalies in compensatable and pivot subtransactions The Commutative Updates Counter-measure can prevent lost updates in all types of subtransactions The Version File Counter-measure can prevent lost updates in all types of subtransactions The Version File and Commutative Updates Counter-measure is a combination of the two countermeasures

9. The history of Dirty read anomaly:

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

11. The history of Phantom anomaly:

12. Countermeasures against dirty reads and non-repeatable read anomalies : w1(x)…r2(x)…a1... The Pessimistic View Countermeasure can reduce the consequenses of dirty reads and non-repeatable read anomalies in all types of subtransactions The Semantic Lock Countermeasure can reduce the consequenses of dirty reads and non-repeatable read anomalies in all types of subtransactions

13. The Pessimistic View Counter-measure: The idea of this countermeasure is to “limit” the options of concurrent users to prevent them in using non existing resources. Therefore, compensatable subtransactions should be used for updates that decrease the users’ options. That is, concurrent transactions cannot use resources that are reserved by a compensatable subtransaction. The retriable subtransactions should be used for updates that “increase” the users’ options. That is, concurrent transactions can only use increased resources after the increase has been committed globally. The pivot subtransactions may be used for updates that “increase” and/or “limit” the users’ options because this update reflects the real world reality.

14. The Pivot Lock Counter-measure : It may be possible to use long duration locks in the pivot location if it is combined with low isolation levels for transaction that decrease the stocks and high isolation levels for transaction that increase the stocks. However, this solution is not recommended in hotspots. Why?

15. The Semantic Lock Counter-measure : May function as a generalization of locking if compensatable subtransactions mark records as locked and retriable subretriable transactions un-marks the marked records after use. However, it is up to the concurrent transactions, how to deal with the markings. The markings need not be restricted to be only exclisive and shared locks. For example, the marking may be common for a special transaction action. In accounting and product stock management, a ”counter” attribute may accumulate the number of compensatable uncommitted stock reductions and in this situation, retriable subtransactions should decrease the number of uncommitted stock reductions. That is, the counter attribute is only zero when no uncommitted transactions are using the stock.

16. Consistency in E commerce systems: What countermeasures are necessary in the non replicated Product-stocks of the ERP system?

17. The history of the Fuzzy read anomaly: (Non-repeatable read) r1(x)…w2(x)… c2…r1(x)…. Examples: If a record is read and updated in different subtransactions, a second transaction may update the record between the read and the reread for update. In the extended transaction models, this may happen as records are not locked across a dialog with the user. The reread countermeasure can detect the anomaly

18. The history of the Phantom anomaly: r1 (P)…w2(y now in P)…c2…r1 (P)... Examples: The phantom anomaly may occur in all transaction models when low SQL isolation levels are used. If consistency is needed and full isolation is unacceptable, it may be a solution to use a data warehouse.

19. Anomalies between a record x and its replica y: The Read skew anomaly illustrates that that a shared lock (read lock) does not exclude the writing of a related record: Read skew: r1(y)…w2(x)… w2(y)…c2… r1(x) …... The Write skew anomaly illustrates that that an exclusive lock (write lock) does not exclude the writing of a related record: 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 the reading of a related record: Asynchronous replication anomaly: w1(x)... r2(y)...c2…w1(y)… c1.

20. Example of the Asynchronous replication anomaly: w1(x)…c1… r2(y)…c2…w1(y)…Asynchronous c1. The replicated object may be patient records that may be created locally in different hospital databases. In this situation, the anomaly may occur when the second transaction cannot read missing Y patient records from other hospitals, and as the patient may have visited any hospital in the world, it can also be difficult to get all the records of a patient.

21. Generalized Asynchronous Replication Anomaly: w1(x)…c1… r2(y)…c2…w1(y)…Asynchronous c1. The asynchronous replication anomaly can be generalized to dependencies between related records in general. Suppose a table has information about persons and all person records have an attribute saying whether the persons are married or not and another attribute saying whether the persons are dead or not. In this case we will assume that x and y are person records where the corresponding persons are married. Suppose transaction 1 mark x to be a dead person and y to be a widow. In this case, transaction 2 may read that y is married even though her husband x is dead. For protection the primary copy countermeasure may be generalized to update/read related records in a fixed order. That is, in this case all related records should be updated before a person record is marked as dead.

22. The replication 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. For protection the primary copy countermeasure may be used to update/read related records in a fixed order.

23. The generalizied read skew anomaly: Read skew: r1(y)…w2(x)… w2(y)…c2… r1(x) …... Example: Suppose a table has information about persons and all person records have an attribute saying whether the persons are married or not and another attribute saying whether the persons are dead or not. In this case we will assume that x and y are person records where the corresponding persons are married. Suppose transaction 2 mark x to be a dead person and y to be a widow. In this case, transaction 1 may read that y is married even though her husband x is dead. For protection the primary copy countermeasure may be generalized to update/read related records in a fixed order. That is, in this case all related records should be updated before a person record is marked as dead.

24. The replication 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. For protection the primary copy countermeasure may be used to update/read related records.

25. The generalizied write skew anomaly: Write skew: r1(x)… r2(y)… w2(y)…w1(x)…c1…c2. Example: Suppose a table has information about persons and all person records have an attribute saying whether the persons are married or not and another attribute saying whether the persons are dead or not. In this case we will assume that x and y are person records where the corresponding persons are married. Suppose transaction 1 mark x to be a dead person and transaction 2 mark y to be a widow. In this case, the database is inconsistent until transaction 1 is committed. For protection the primary copy countermeasure may be generalized to update/read related records in a fixed order. That is, in this case all related records should be updated before a person record is marked as dead.

26. The read skew anomaly may occur when a first transaction reads two related records while a second transaction updates the related records between the readings of the first transaction. r1(x)…w2(x)… w2(y)…c2… r1(y)…... Example: Referential integrity may say that the parent record y must exist for a any child record x. If for example the second transaction deletes the records x and y, the first transaction cannot find the parent record y and this may violate the database integrity. The timestamp countermeasures may protect against the Read Skew Anomaly

27. The write skew anomaly may occur when a first transaction reads and later writes a record while a second transaction reads and updates a related record between the read and write of the first transaction. r1(x)… r2(y)… w2(y)…w1(x)…c1…c2. Example: The write skew anomaly might arise from constraints at a bank, where account balances are allowed to go negative as long as the sum of commonly held balances remains non-negative. A read timestamp may protect against the Write Skew Anomaly

28. The history of the Read skew anomaly: r1(x)…w2(x)… w2(y)…c2… r1(y)…... Suppose x is Fact data while y is Dimension data in a datawarehouse. That is, the interpretation of x data depends on the attribytes of y. As Fact data normally is not updated the relevant Read skew history is redused to r1(x)… w2(y)…c2… r1(y)… From an information point of view this Read skew history is equivalent to following history as x is not changed. … w2(y)…c2… r1(x)… r1(y)… However, this is the history of an OLAP transaction r1 that reads datawarehouse data after a change in a Slowly Changing Dimension y. Therefore, the Read skew anomaly may be viewed as a special case of the problem of Slowly Changing Dimensions. Anyway, the responses 2, 5 and 7 to Slowly Changing Dimensions and temporal timestamps may often be used as countermeasures against the Read skew anomaly. For example, in temporal datawarehouses event data has a time stamp and dimension data has a ”start” and ”end” timestamp corresponding to the validity of the dimension attributes. Such timestamps may worn the users against the Skew anomalies as the records x and y have different transaction timestamps in case a skew anomaly has occured.

29. The history of the Asynchronous replication anomaly: w1(x)…c1… r2(y)…c2…w1(y)…Asynchronous retriable c1. In its most simple form, the asynchronous replication anomaly occurs when a primary record is updated by a first transaction while a second transaction reads an outdated secondary copy. The primary copy countermeasure can protect against the anomaly. However, in practice the primary copy are only used in case of updates.

30. The history of the Asynchronous replication anomaly: w1(x)…c1… r2(y)…c2…w1(y)…Asynchronous retriable c1. 1.Is the Asynchronous replication anomaly acceptable when the address of a customer is changed? 2.Is the Asynchronous replication anomaly acceptable when the amount of available airplane tickets are red by B2C e- commerce? 3.Is the Asynchronous replication anomaly acceptable when you want to read the diagnoses of a patient? 4.Is the Asynchronous replication anomaly acceptable if you want to change the diagnoses of a patient? 5.Is the Asynchronous replication anomaly acceptable when you have to decide whether to give a loan to a customer?

31. Consistency between E commerce/ERP systems: What countermeasures are necessary in the replicated Product, Order, and Orderline tables? What countermeasures are necessary in the replicated Customer table if it does not have a balance attribute? What countermeasures are necessary in the replicated Customer table if it does have a balance attribute?

32. The retimestamping countermeasure The countermeasure uses two timestamps stored in each record. One timestamp is provided by the creating transaction and one by the system where the record copy is stored by the basic 0-safe design. The time interval between the two timestamps is a local warning that indicates when the asynchronous replication anomaly may have occurred. The retimestamping countermeasure cannot prevent the asynchronous replication anomaly, but it makes it possible to correct information stored by transactions that were executed while the asynchronous replication anomaly may have occurred. By using Artificial Intelligence (AI) the correction may be done automatically.

33. Design a Distributed Airline Database Design local databases and the workflow of an integrated distributed database that integrate the e-commerce sale of different airline companies in a way that optimize performance, availability and consistency of a common distributed airline system with local databases in the airline companies, airports, and “sale offices” at e.g. travel agents, hotels and e-commerce servers. (Do not use a GDS in this exercise).

34. Exercise: Design local databases and the workflow of an integrated distributed database that integrate the e-commerce sale of different airline companies, hotel chains in a way that optimize performance, availability and consistency of a common distributed system with local databases in the airline companies, hotel chains, airports, car rental companies, and “sale offices” at e.g. travel agents, hotels and e- commerce servers. (Do not use a GDS in this exercise). Describe the workflow of the integrated e-commerce system.

35. Exercise How would you recommend integrating two airline companies? Does it make any difference whether the companies are in alliance or not? What problems may occur if travel arrangements are converted while some of the flights are not finished yet? Can the ideas of a distributed modular ERP system be used?

36. Exercise: A GDS (Global Distribution Service) is a worldwide computerized reservation system for reserving airline tickets, hotel rooms, rental cars, and other travel related items. The largest GDSs are Amadeus, Galileo, Sabre, and Worldspan. Design an integrated distributed database that integrate the databases of different airline companies and hotel chains in a way that optimize performance, availability and consistency of a common distributed system with local databases in GDSs, the airline companies, hotel chains, airports, and “sale offices” at e.g. travel agents, hotels and e-commerce servers. The relationships of the diagram illustrate that a travel product stored in one system may be stored in many other systems from where data are replicated in sequence from left to right between the different types of systems. How would you design relaxed ACID properties in the global distributed system?

37. End of session Thank you !!!

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