Presentation is loading. Please wait.

Presentation is loading. Please wait.

Why should a database transaction be atomic?. ABORT = Removal of the updates of a transaction An abort is implemented by a DBMS roll back recovery where.

Similar presentations


Presentation on theme: "Why should a database transaction be atomic?. ABORT = Removal of the updates of a transaction An abort is implemented by a DBMS roll back recovery where."— Presentation transcript:

1 Why should a database transaction be atomic?

2 ABORT = Removal of the updates of a transaction An abort is implemented by a DBMS 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 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?

5 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?

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

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

8 The Relaxed Atomicity Property: Committing subtransaction Root transaction How would you implement the different types of the 0-safe design by using relaxed atomicity?

9 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

10 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

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

12 Architecture for PULL Update Propagation from A to B: System A System B Local database including a transaction file. Local database including a state record.

13 Architecture for PUSH Update Propagation from A to B: Local database including a transaction file. System A System B

14 PULL versus PUSH Update Propagation: PULL UPs are batch orientated, as transaction records are only transferred periodically. PULL UPs have smaller execution cost. PULL UPs have a smaller programming cost. PULL UPs of transaction records are single threaded. PULL UPs may be initiated by a push. PULL replication from a primary copy may have lost transactions but not lost update anomalies.

15 Structure of a global update transaction: [The user starts to read data] The user enters data for the update process. The user starts the update using the model with compensatable, pivot, and retriable subtransactions.

16 UML-Statechart diagram for a global transaction Syntax for State diagrams: Event [condition] /Action

17 Routing by using flexible transactions. Question 1. Describe a Petri net workflow for flexible transactions. Question 2. Change the Petri net workflow in such a way that it also functions for recovered transactions. Syntax for the State diagram: Event [condition] Action

18 Architecture of a WFMS: The pattern of a flexible transaction may be viewed as the core of a workflow engine.

19 The main problems of mobile computing: Disconnections Location dependency Resource constraints Low bandwidth

20 The disconnection problem:

21 The location dependency problem:

22 Push message propagation:

23 Pull message propagation:

24 Pull message propagation after motion:

25 Mobile IP address:

26 Mobile IP and push message propagation:

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

28 Exercise: Describe and design an integrated distributed database including mobile databases where an e-commerce supplier can deliver its products direct to its customers and at the same time get automatic acknowledgement for the delivery in both the database of the supplier and the customer. Describe also the integrated workflow of the integration. Can the earlier described distributed ERP system be used?

29 Workflow for making mobile control of supplier deliveries. Delivery larger than ordered Delivery matches an Orderline Delivery less than ordered Delivery is not ordered Select a con- trol action Product deliveries Orderlines are replicated to the mobile controllers New Supplier orders. Orderlines Reduced product delivery AND JOIN Update the local stock Replicate the mobile registrations to the central ERP system Error reports Accepted product deliveries Accepted product deliveries End of workflow AND SPLIT Reduced orderline Input Input is supplier orders or deliveries.

30

31 End of session Thank you !!!

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


Download ppt "Why should a database transaction be atomic?. ABORT = Removal of the updates of a transaction An abort is implemented by a DBMS roll back recovery where."

Similar presentations


Ads by Google