1. Universität Karlsruhe (TH) © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Chapter 9 Distributed Transactions: Characteristics

2. 2 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 from now on until now Transactions Computing process 1 Resource manager 1 Process step 1 Resource manager 2Resource manager 3Resource manager 4 Process step 2Process step 3Process step 4 Process step 3Process step 2Process step 1Process step 5 Computing process 2 database transaction application transaction

3. 3 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Distributed transactions Computing process 1 Resource manager 1 Process step 1 Resource manager 2Resource manager 3Resource manager 4 Process step 2Process step 3Process step 4 Process step 3Process step 2Process step 1Process step 5 Computing process 2 database transactions application transaction1 n distributed across m managers

4. 4 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Complication: Autonomy Computing process 1 Resource manager 1 Process step 1 Resource manager 2Resource manager 3Resource manager 4 Process step 2Process step 3Process step 4 Process step 3Process step 2Process step 1Process step 5 Computing process 2 database transactions application transaction1 n distributed across m managers Modern complication: All servers – hence, all data servers – are autonomous!

5. 5 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Autonomie Jedes DBMS ist in dreierlei Hinsicht autonom: Entwurfs-Autonomie: Unabhängigkeit bzgl. verwendetem Datenmodell, logischem und physikalischem Entwurf, Anfragesprache, Protokollen für Nebenläufigkeitskontrolle und Recovery. Ausführungs-Autonomie: Lokale Transaktionen werden von den DBMS selbständig und ohne Kommunikation bearbeitet. Teile von globalen Transaktionen, die ein DBMS bearbeitet, werden wie lokale Transaktionen behandelt. Kommunikations-Autonomie: DBMS können mit anderen Systemen kommunizieren, können aber weder zur Kommunikation an sich, noch zu einem Zeitpunkt für die Kommunikation gezwungen werden.

6. 6 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 DBMS Federations Modern focus: Heterogeneous federation: Participating servers are autonomous and independent; have no uniformity of protocols; their distribution is transparent to users.

7. 7 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Complication: More failure potential Computing process 1 Resource manager 1 Process step 1 Resource manager 2Resource manager 3Resource manager 4 Process step 2Process step 3Process step 4 Process step 3Process step 2Process step 1Process step 5 Computing process 2 database transactions application transaction1 n distributed across m managers Not only data servers may fail, but also communication links!

8. 8 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Objective and problems (1) Computing process 1 Resource manager 1 Process step 1 Resource manager 2Resource manager 3Resource manager 4 Process step 2Process step 3Process step 4 Process step 3Process step 2Process step 1Process step 5 Computing process 2 database transactions application transaction1 n distributed across m managers Consistency problem 1: Isolation of application transactions Can we still enforce serializability? Ideally: Application transactions are ACID.

9. 9 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Objective and problems (2) Computing process 1 Resource manager 1 Process step 1 Resource manager 2Resource manager 3Resource manager 4 Process step 2Process step 3Process step 4 Process step 3Process step 2Process step 1Process step 5 Computing process 2 database transactions application transaction1 n distributed across m managers Consistency problem 2: Atomicity of application transactions Can we still enforce all-or-nothing? Ideally: Application transactions are ACID.

10. 10 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 3-Tier Reference Architecture (1) Stored Data (Pages) Data Server Application Server Clients Users... Application Program 1 Application Program 2... Objects encapsulated data exposed data RequestReply RequestReply © Weikum, Vossen, 2002

11. 11 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 3-Tier Reference Architecture (2)... Application Program Application Program... Objects encapsulated data exposed data Application Program Application Program... Objects encapsulated data exposed data... Objects encapsulated data exposed data.

12. 12 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Local enforcement! What do we have to do to obtain global atomicity? Local enforcement! What do we have to do to obtain global isolation? Local server architecture Transaction 1Transaction 2... Transaction n Scheduler Database Manager Database Backup/Recovery Manager restart Archive Manager restore AtomicityDurability Consistency Isolation

13. 13 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Local Transaction Managers Global Transaction Manager Global (application) Transactions... Local (database) Transactions GTM LTM Federation Model autonomous server Middleware

14. 14 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Local Transaction Managers Global Transaction Manager Global (application) Transactions... Local (database) Transactions GTM LTM Distributed Transaction Model (1) home/coordinator node: The node that starts the transaction, i.e., executes BOT. Issues all other DB operations including commit. Distributed or global transaction across several nodes. Local transaction: executed exclusively at one node (all data available there).

15. 15 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Distributed Transaction Model (2) Local and global transactions are sequential (total order of DB operations). Each global transaction starts in each local DBMS at most one local (sub-)transaction. Global transactions invoke commit in each local DBMS where they are active. Replications of data are not recognized as such.

16. 16 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Distributed Transaction Model (3) US Customers German Customers Home node Global transaction: Transfer USD 500,-- from Klemens account to Jims account. Increment Jims balance. Record receipt of money from Klemens. Decrement Klemens balance. Record transfer of money to Jim. (local) subtransactions

17. 17 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Transaction tree not balanced, height only limited by number of nodes, subtransactions may execute in parallel. Subtransactions invoked by primary transaction. Distributed Transaction Model (4) T1 T2T3... Tn T4T5 T6 Primary transaction (root transaction) – subtransaction executed at home node. Subtransaction invokes further subtransactions at other nodes.

18. 18 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Transaction execution Transaction starts from the home site, results are returned from there. If the LTM at the home site cannot execute an operation, GTM passes them on to the LTM of some other suitable node. Subtransaction may concurrently execute at the various nodes.

19. 19 © 2007 Univ,Karlsruhe, IPD, Prof. Lockemann/Prof. BöhmTAV 9 Einfluss der Autonomie Es kann lediglich unterstellt werden, dass jedes lokale System für lokale Isolation und Atomizität sorgt, aber nicht wie. Der GTM hat keinen Einfluss auf die Ausführung lokaler Transaktionen. Er kann Kollisionen zwischen globalen und lokalen Transaktionen nicht verhindern. Subtransaktionen können in einem lokalen DBMS abstürzen und in anderen nicht. Der Abbruch lokaler Transaktionen wird außen nicht bemerkt. How to adapt scheduling protocols to maintain serializability? How to adapt recovery protocols to maintain atomicity?