Złożona struktura transakcji

Złożona struktura transakcji

Ograniczenia płaskiej struktury transakcji Planowanie wyjazdu Poznań Rockford k Chicago BEGIN WORK S1: zarezerwuj lot z Poznania do Frankfurtu S2: zarezerwuj lot z Frankfurtu do Nowego Jorku (tego samego dnia) S3: zarezerwuj lot z Nowego Jorku do Chicago (tego samego dnia) S4: zarezerwuj przejazd autobusem z Chicago do Rockford S5: zarezerwuj hotel w Rockford ROLLBACK Problem: nie ma tego dnia wolnych miejsc w hotelu w Rockford kchicago, ale można tanio wynająć pokój w hotelu w Chicago Implementacja w klasycznym modelu transakcji: Pojedyncza transakcja wycofanie rezerwacji S4 pociągnie za sobą utratę rezerwacji S1, S2 i S3 Zbiór logicznie powiązanych transakcji: nie można wycofać transakcji S1, S2 i S3 Klasyczny model transakcji nie odpowiada potrzebom aplikacji o złożonej strukturze przetwarzania

Transakcje intensywnie przetwarzające dane Doliczenie odsetek jedna duża transakcja DoliczOdsetki ( ) { exec sql BEGIN WORK; pobierz(procent); for (nr_konta = 1; nr_konta <= 100000; nr_konta++) ModyfikujKonto(nr_konta, odsetki); exec sql COMMIT WORK; return; } ModyfikujKonto(nr_konta long, odsetki float) { exec sql UPDATE konta SET saldo = saldo + (SELECT SUM(odsetki* ) FROM operacje WHERE ) WHERE id_konta = :nr_konta; return; }; W przypadku awarii duża ilość utraconej pracy Niski stopień współbieżności Duże obciążenie dla systemu: duża ilość blokad oraz wielkość logu wycofania transakcji

Przykład II Doliczenie odsetek zbiór autonomicznych transakcji DoliczOdsetki ( ) { pobierz(procent); for (nr_konta = 1; nr_konta <= 100000; nr_konta++) ModyfikujKonto(nr_konta, odsetki); return; } ModyfikujKonto(nr_konta long, odsetki float) { exec sql BEGIN WORK; exec sql UPDATE konta SET saldo = saldo + (SELECT SUM(odsetki* ) FROM operacje WHERE ) WHERE id_konta = :nr_konta; exec sql COMMIT WORK; return; }; Wysoka współbieżność pracy systemu Niskie obciążenie systemu W przypadku awarii systemu niespójność, utrata kontekstu pracy aplikacji

Rozszerzenia płaskiego modelu transakcji Zarządzanie przepływami pracy System powinien wspomagać zarządzanie wyodrębnionymi fragmentami długich transakcji Minimalizacja traconej pracy - System powinien umieć dzielić transakcje przetwarzające duże ilości danych na mniejsze odtwarzalne fragmenty w przypadku awarii procesu przetwarzania Zwiększenie współbieżności przetwarzania System powinien minimalizować blokowanie zasobów przez długo trwające transakcje Zawieszanie procesu przetwarzania transakcji System powinien umożliwiać zawieszanie procesu przetwarzania długo trwających transakcji i ich ponowne uruchamianie od momentu, w którym nastąpiło zawieszenie

Płaskie transakcje z punktami wycofania (ang savepoints) Nowe operacje definiujące strukturę transakcji: SAVE WORK: savepoint ROLLBACK WORK (savepoint) BEGIN WORK ( SAVE WORK: 1) Operacja Operacja SAVE WORK: 2 Operacja SAVE WORK: 3 Operacja Operacja SAVE WORK: 4 Operacja ROLLBACK WORK(2) Operacja Operacja SAVE WORK: 5 Operacja SAVE WORK: 6 Operacja Operacja SAVE WORK: 7 Operacja ROLLBACK WORK(5) Operacja Operacja SAVE WORK: 8 Operacja COMMIT WORK Trwałe punkty wycofania

Nowa operacja: Łańcuch transakcji CHAIN WORK = COMMIT WORK + BEGIN WORK T i begin commit T i+1 begin commit CHAIN WORK T i : Atomowa operacja: { * COMMIT WORK T i ; * BEGIN WORK T i+1 ; } ROLLBACK WORK T i : Atomowa operacja: { * ROLLBACK WORK (T i ); * BEGIN WORK (T i ); } Restart systemu po awarii w trakcie transakcji T i : Atomowa operacja: { * ROLLBACK WORK (T i ); * BEGIN WORK (T i ); } ROLLBACK WORK łańcuch transakcji:???

Przenoszenie i odtwarzanie kontekstu transakcji DoliczOdsetki ( ) { pobierz(procent); for (nr_konta = 1; nr_konta <= 100000; nr_konta++) ModyfikujKonto(nr_konta, odsetki); return; } ModyfikujKonto(nr_konta long, odsetki float) { exec sql BEGIN WORK; exec sql UPDATE konta SET saldo = (1 + procent saldo) * saldo; WHERE id_konta = nr_konta; exec sql COMMIT WORK; return; };

SAGA Cel zwiększenie stopnia współbieżności transakcji 1 Zdefiniowanie łańcucha transakcji jako pojedynczej jednostki sterowania 2 Saga jest jednostką atomowości, ale nie izolacji 3 Atomowość całego łańcucha transakcji jest zapewniana w wyniku zastosowania transakcji kompensacyjnych SAGA jest zbiorem płaskich transakcji s 1, s 2,s n Transakcje te mogą być wykonywane sekwencyjnie lub współbieżnie Każdej transakcji s i (1 i n) odpowiada transakcja kompensacyjna cs i, która wycofuje efekt działania transakcji s i Wynikiem poprawnego wykonania SAGI będzie sekwencja: s 1,s 2,,s i,,s n-1,s n natomiast w przypadku wystąpienia błęu podczas wykonywania kroku j SAGI, wynikiem będzie sekwencja: s 1,s 2,,s j (abort),cs j-1,,cs 2,cs 1

Własności Transakcje zagnieżdżone 1 Transakcje mają złożoną strukturę pozwalającą definiować związki między podzbiorami operacji w ramach pojedynczej transakcji W ogólności jest to struktura hierarchiczna 2 Korzeniem tej hierarchii jest transakcja główna (ang top level transaction), a pozostałe węzły są pod-transakcjami 3 Pod-transakcje danej transakcji mogą być współbieżne BEGIN WORK call subtransaction call subtransaction COMMIT WORK BEGIN WORK call subtransaction call subtransaction COMMIT WORK BEGIN WORK COMMIT WORK BEGIN WORK COMMIT WORK BEGIN WORK COMMIT WORK Różne modele transakcji zagnieżdżonych: otwarte zamknięte wielopoziomowe

Typy pod-transakcji Czy pomyślne zakończenie transakcji powinno być uzależnione od sposobu zakończenia jej podtransakcji? Model transakcji zagnieżdżonych przewiduje istnienie dwóch podstawowych typów pod-transakcji: transakcje krytyczne (ang vital sub-transaction), których niepomyślne zakończenie powoduje wycofanie całej transakcji transakcje niekrytyczne (ang non vital sub-transaction), których niepomyślne zakończenie nie ma wpływu na sposób zakończenia całej transakcji Organizacja wczasów: BEGIN WORK T 1 T 11 :organizacja podróży (vital) T 12 : rezerwacja hotelu (vital) T 13 : rezerwacja luksusowego samochodu (non vital) T 14 : rezerwacja dodatkowych atrakcji (non vital) COMMIT WORK

Typy pod-transakcji Z pod-transakcjami krytycznymi mogą być powiązane transakcje warunkowe (ang contingency), które są wykonywane jedynie w wypadku niepomyślnego zakończenia pod-transakcji krytycznych Transakcje warunkowe służą do definiowania alternatywnych sposobów realizacji określonych zadań BEGIN WORK T 1 T 111 : rezerwacja samolotu when failed then T 112 : rezerwacja pociągu (contingency) Sposobem umożliwiającym zwalnianie zasobów systemowych przydzielonych zakończonym pod-transakcjom są transakcje kompensujące Transakcje kompensujące muszą być zdefiniowane dla wszystkich pod-transakcji Wykonują one działania przywracające stan bazy danych sprzed wykonania powiązanych z nimi pod-transakcji BEGIN WORK T 1 T 11 : rezerwacja samolotu; CT 11 : wycofanie rezerwacji samolotu;

Zależności między pod-transakcjami W przeciwieństwie do transakcji głównej podtransakcje nie posiadają cechy trwałości D Reguła zatwierdzania - Zatwierdzenie pod-transakcji powoduje, że wprowadzone przez nią modyfikacje stają się dostępne (jedynie) dla transakcji rodzicielskiej Podtransakcja zostaje ostatecznie zatwierdzona jedynie, jeżeli jest lokalnie zatwierdzona i wszystkie transakcje rodzicielskie aż do korzenia drzewa zostaną zatwierdzone COMMIT T i WHEN T committed COMMIT WORK; Reguła wycofywania - Jeżeli transakcja (pod-transakcja) jest wycofywana to jej wszystkie pod-transakcje potomne również zostaną wycofane, niezależnie od ich lokalnego stanu zatwierdzenia Wycofywanie pod-transakcji jest rekurencyjnie stosowane do kolejnych niższych poziomów drzewa Wycofywanie transakcji w korzeniu drzewa prowadzi do wycofania wszystkich podtransakcji składających się na transakcję zagnieżdżoną

Zamknięte i otwarte transakcje zagnieżdżone W zamkniętym modelu transakcji zagnieżdżonych transakcje główne posiadają wszystkie cechy ACID, a pod-transakcje cechy ACI Reguła izolacji - Wszystkie modyfikacje wprowadzone przez pod-transakcje są widoczne dla transakcji rodzicielskich po lokalnym zatwierdzeniu pod-transakcji Wszystkie obiekty utrzymywane przez transakcję rodzicielską są dostępne dla jej transakcji potomnych Podtransakcje są w pełni izolowane od wszystkich innych pod-transakcji wewnątrz i na zewnątrz ich transakcji rodzicielskiej Blokady pod-transakcji są dziedziczone przez transakcje rodzicielskie W otwartym modelu transakcji zagnieżdżonych transakcja główna nie posiada cechy izolacji, cecha ta jest własnością pod-transakcji, które są liśćmi hierarchii transakcji Umożliwia to zwiększenie stopnia współbieżności transakcji i zmniejszenie obciążenia systemów

Transakcje wielopoziomowe Transakcje wielopoziomowe są rozszerzeniem modelu transakcji zagnieżdżonych o wykorzystanie semantyki operacji Kolejne poziomy zagnieżdżenia transakcji adresują warstwy semantyczne bazy danych Każda warstwa jest zbiorem dobrze zdefiniowanych abstrakcyjnych typów danych Najniższy poziom tworzy warstwa elementarnych i niepodzielnych operacji Krotki: warstwa 2 {wstaw, czytaj, modyfikuj, usuń} Pliki: warstwa 1 {otwórz, zamknij, czytaj rekord, zapisz rekord} Strony: warstwa 0 {czytaj, zapisz, modyfikuj nagłówek}

Implementacja operacji semantycznych Operacje semantyczne wykonywane w warstwie n są implementowane jako pod-transakcje wykonywane w warstwie n-1 zapisz_rekord(r) czytaj(p) modyfikuj_nagłówek(p) zapisz(p) Ze względu na topologię hierarchii transakcje wielopoziomowe są szczególnym przypadkiem modelu transakcji zagnieżdżonych, w którym hierarchie transakcji są zrównoważone i wszystkie mają taką samą wysokość

Własności transakcji wielopoziomowych Model transakcji wielopoziomowych pozwala na zwiększenie stopnia współbieżności transakcji zagnieżdżonych, przy zachowaniu cechy izolacji transakcji Przykład: Dwa poziomy abstrakcji: rekordy: operacje read(rekord) i write(rekord) strony dyskowe: operacje fetch(page) i store(page) T 1 T 2 r 2 (r4) r 1 (r1) w 2 (r3 6) w 1 (r2 3) w 2 (r2 4) f 2 (q) f 2 (p) f 1 (p) s 2 (p) f 1 (p) s 1 (p) f 2 (p) s 2 (p) Operacje na środkowym poziomie hierarchii nie są atomowe, jednak odpowiadające im podtransakcje są uszeregowalne Dzięki temu, mimo braku pełnej uszeregowalności najniższego poziomu transakcji, historia transakcji T 1 i T 2 jest poprawna stan przed: stan po: page: p: r1 = 1; r2 = 2; r3 = 3; page: p: r1 = 1; r2 = 4; r3 = 6; page: q: r4 = 0 page: q: r4 = 0

Przykład historii niepoprawnej T 1 T 2 r 2 (r4) r 1 (r1) w 2 (r3 6) w 1 (r2 3) w 2 (r2 4) f 2 (q) f 2 (p) f 1 (p) f 1 (p) s 2 (p) s 1 (p) f 2 (p) s 2 (p) Transakcje implementujące operacje środkowego poziomu hierarchii nie są uszeregowalne: transakcje odpowiadające operacjom w 2 (r3) i w 1 (r2) stan przed: stan po: page: p: r1 = 1; r2 = 2; r3 = 3; page: p: r1 = 1; r2 = 4; r3 = 3; page: q: r4 = 0 page: q: r4 = 0 Synchronizacja ograniczona do najwyższego poziomu abstrakcji jest niewystarczająca Powyższa historia jest niepoprawna, mimo że operacje semantyczne na poziomie środkowym są niekonfliktowe Konflikty (z punktu widzenia komutatywnych operacji warstwy wyższej są to pseudo-konflikty) występują na najniższej warstwie, a zawierające je pod-transakcje są nieuszeregowalne Niepoprawność powyższej historii transakcji wynika z braku atomowości operacji wyższych poziomów abstrakcji

Wielopoziomowa synchronizacja transakcji zagnieżdżonych Wielopoziomowa synchronizacja transakcji zagnieżdżonych polega na niezależnej synchronizacji transakcji (potransakcji) w oddzielnych warstwach Każda warstwa obejmuje po dwa poziomy abstrakcji: niższy widziany jako zbiór operacji; wyższy widziany jako zbiór transakcji T 1 T 2 r 2 (r4) r 1 (r1) w 2 (r3 6) w 1 (r2 3) warstwa I w 2 (r2 4) warstwa II f 2 (q) f 2 (p) f 1 (p) f 1 (p) s 2 (p) s 1 (p) f 2 (p) s 2 (p) Niezależność warstw pozwala na stosowanie w różnych warstwach różnych algorytmów synchronizacji

Uszeregowalność wielopoziomowa Wielopoziomowa historia transakcji jest parą: WHT = (F, <) gdzie: F jest lasem drzew transakcji; < jest relacją częściowego porządku zdefiniowana na zbiorze węzłów Relacja < jest sumą relacji porządkujących węzły na poszczególnych poziomach drzew Relacja < 0 jest relacją porządkującą operacje atomowe reprezentowane przez liście drzew Relacja < 0 może być uporządkowaniem częściowym Jednak relacja ta musi być określona dla wszystkich par operacji, dla których zachodzi relacja konfliktowości CON 0 Relacje częściowego porządku < i określające kolejność operacji na wyższych poziomach hierarchii transakcji są zdefiniowane następująco: operacja x poprzedza operację y w warstwie i wtedy i tylko wtedy, gdy wszyscy potomkowie operacji x poprzedzają wszystkich potomków operacji y W przeciwnym wypadku operacje x i y są współbieżne

Uszeregowalność wielopoziomowa Na każdym poziomie abstrakcji można określić quasiporządek operacji < Na poziomie 0 porządek ten określa ~ i jedynie kolejność operacji konfliktowych, to jest: < = < 0 CON 0 ~ 0 Dla dowolnego wyższego poziomu i, dwie operacje f i g występują w zależności f < g, wtedy i tylko wtedy, gdy ~ i mają potomków f i g na poziomie i-1, którzy są w relacji konfliktowej i f < g ~ i 1 Dla dwu poziomowego lasu, quasi-porządek < odpowiada ~ i grafowi uszeregowalności transakcji Stąd klasyczna teoria uszeregowalności może być traktowana jako szczególny przypadek uszeregowalności wielopoziomowej Definicja Dana wielopoziomowa historia transakcji jest uszeregowalna, wtedy i tylko wtedy, gdy dla każdego poziomu lasu i, relacja < (< i CON i ) jest acykliczna ~ i

Uszeregowalność wielopoziomowa Dla danej wielopoziomowej historii transakcji jej uszeregowalność może być zweryfikowana poprzez próbę zwinięcia lasu do korzeni poszczególnych transakcji za pomocą operacji przestawiania węzłów i redukcji poziomów, w następujący sposób: dla każdego poziomu, poczynając od poziomu 0, wyizoluj poddrzewa pod-transakcji przestawiając węzły niekonfliktowych operacji; zredukuj wyizolowane poddrzewa do ich korzeni; Jeżeli jest możliwe zwinięcie lasu drzew do korzeni reprezentujących główne transakcje wielopoziomowa historia jest uszeregowalna i jest równoważna uzyskanej historii sekwencyjnej

Przykład 1) Rozplątanie poddrzew w najniższej warstwie T 1 T 2 r 2 (r4) r 1 (r1) w 2 (r3 6) w 1 (r2 3) w 2 (r2 4) f 2 (q) f 2 (p) f 1 (p) s 2 (p) f 1 (p) s 1 (p) f 2 (p) s 2 (p) przestawienie 2) Redukcja poziomów T 1 T 2 r 2 (r4) r 1 (r1) w 2 (r3 6) w 1 (r2 3) w 2 (r2 4) redukcja f 2 (q) f 1 (p) f 2 (p) s 2 (p) f 1 (p) s 1 (p) f 2 (p) s 2 (p)

3) Rozplątanie poddrzew w kolejnej warstwie T 1 T 2 r 2 (r4) r 1 (r1) w 1 (r2 3) w 2 (r3 6) w 2 (r2 4) przestawienie 4) Redukcja poziomów T 1 T 2 redukcja r 1 (r1) w 1 (r2 3) r 2 (r4) w 2 (r3 6) w 2 (r2 4) 5) Uszeregowalna historia wielopoziomowa T 1 T 2

Ograniczenia modelu transakcji wielopoziomowych Struktura transakcji wielopoziomowych musi spełniać następujące wymagania: 1 Hierarchia abstrakcji Transakcja jest hierarchią podtransakcji Pod-transakcje w zależności od ich położenia w hierarchii (odległości od korzenia) należą do określonego poziomu abstrakcji Pod-transakcje należące do określonego poziomu abstrakcji tworzą wyodrębnione warstwy transakcji 2 Warstwy transakcji Wyodrębnione warstwy są całkowicie hermetyczne Pod-transakcje należące do warstwy n są kompletnie zaimplementowane przez podtransakcje warstwy n-1 3 Regularność struktury hierarchii Niedopuszczalne są wywołania między warstwami transakcji, które nie sąsiadują ze sobą

Atomowość transakcji wielopoziomowych Pod-transakcje bezpośrednio po ich zatwierdzeniu udostępniają wyniki swojej pracy Zwiększa to stopień współbieżności transakcji W związku z tym atomowość transakcji musi być zapewniona poprzez wykorzystanie transakcji kompensacyjnych Reguła zatwierdzania Pod-transakcja jest zatwierdzana niezależnie od jej transakcji rodzicielskiej Jej zatwierdzenie odblokowuje użycie skojarzonej z nią transakcji kompensującej Zatwierdzenie wszystkich transakcji rodzicielskich aż do korzenia drzewa nie ma żadnego wpływu na stan podtransakcji Jeżeli jednak któraś z transakcji rodzicielskich z korzeniem drzewa transakcji włącznie zostanie wycofana, to spowoduje to uruchomienie transakcji kompensującej, która z definicji musi zostać zatwierdzona Reguła wycofywania Jeżeli transakcja (pod-transakcja) jest wycofywana to dla wszystkich jej pod-transakcji potomnych uruchamiane są transakcje kompensujące, które muszą zostać zatwierdzone Uruchamianie transakcji kompensujących pod-transakcje jest rekurencyjnie stosowane do kolejnych niższych poziomów drzewa Wycofywanie transakcji w korzeniu drzewa prowadzi do skompensowania wszystkich zatwierdzonych pod-transakcji

Zarządzanie współbieżnym wykonywaniem transakcji w obiektowych bazach danych Idea Złożone abstrakcyjne typy danych tworzą wielowarstwową architekturę bazy danych Transakcje w na złożonych obiektach są naturalnymi hierarchiami pod-transakcji Rolę pod-transakcji pełnią metody skojarzone z obiektami Transakcje są, więc sekwencjami wywołań metod skojarzonych z obiektami, które rekursywnie wywołują metody obiektów składowych

Przykładowa baz danych Baza danych jest zbiorem hermetycznych obiektów o strukturze hierarchicznej Wierzchołkiem tej hierarchii są obiekty typu Items reprezentujące produkty sprzedawane przez hurtownię Struktura obiektów typu Item obejmuje atrybuty atomowe reprezentujące: identyfikatory (ItemNo), nazwy (Name), ceny jednostkowe (Price) i stany magazynowe (QOH) poszczególnych produktów oraz atrybut wielowartościowy (Orders) reprezentujący zbiór złożonych zamówień na dany produkt Struktura obiektów typu Order obejmuje tylko atrybuty atomowe reprezentujące: identyfikator zamówienia (OrderNo), identyfikator zamawiającego (CustomerNo), wielkość zamówienia (Quantity) i status jego realizacji (Status) ItemNo Items: set of Item Item Price Orders: set of Order Name QOH Order OrdeNo Quantity CustomerNo Status

Przykładowa baza danych Metody klasy Item i NewOrder (CustomerNo, Quantity) returns OrderNo wstawia nowe zamówienie do zbioru zamówień produktu i, oraz ustawia status zamówienia na wartość new i ShipOrder (OrderNo) reprezentuje operację wysłania produktu i do klienta, poprzez zmniejszenie wartości atrybutu QOH o wielkość Quantity i PayOrder (OrderNo) reprezentuje operację opłacenia zamówienia i przez klienta i TotalPayment () returns Money oblicza całkowitą wartość wszystkich opłaconych zamówień na produkt i Metody klasy Order o ChangeStatus (event) zmień status zamówienia o przez ustawienie flagi event Status zamówienia może być następujący: new, shipped, paid, shipped&paid o TestStatus (event) returns Boolean sprawdza status zamówienia o i zwraca jedną z wartości true lub false Metody atrybutów atomowych a Get ( ) - odczytuje wartość atrybutu a a Put ( ) - modyfikuje wartość atrybutu a

Transakcja wielopoziomowa w obiektowej bazie danych BEGIN WORK i1 ShipOrder(o1) i2 ShipOrder(o2) COMMIT WORK BEGIN WORK o1 ChangeStatus (shipped) i1(qoh) Get( ) i1(qon) Put( ) COMMIT WORK BEGIN WORK o2 ChangeStatus (shipped) i2(qoh) Get( ) i2(qoh) Put( ) COMMIT WORK BEGIN WORK o1(status) Get( ) o1(status) Put( ) COMMIT WORK BEGIN WORK o2(status) Get( ) o2(status) Get( ) COMMIT WORK

Matryce kompatybilności Wywołanie metod f i g na tym samym obiekcie Item jest komutatywne wtedy i tylko wtedy, gdy dwie dowolne sekwencyjne realizacje zawierające metody f i g oraz dowolne inne metody obiektu Item są nierozróżnialne: przez końcowy stan obiektu Item; przez wartości zwracane przez metody f i g Założenie: dostawa produktu jest niezależna od tego, czy zapłacono za zamówienie

Matryca kompatybilności metod obiektów klasy Item Item NewOrder (CustomerNo, Quantity) OrderNo ShipOrder (OrderNo) NewOrder (CustomerNo, Quantity) OrderNo ShipOrder (OrderNo) PayOrder (OrderNo) TotalPayment OK konflikt konflikt OK konflikt konflikt OK OK PayOrder (OrderNo) konflikt OK konflikt konflikt TotalPayment OK OK konflikt OK

Matryca kompatybilności metod obiektów klasy Order Order ChangeStatus (o, shipped) ChangeStatus (o, paid) TestStatus (o, shipped) TestStatus (o, paid) ChangeStatus (o, shipped) OK OK konflikt OK ChangeStatus (o, paid) OK OK OK konflikt TestStatus (o, shipped) TestStatus (o, paid) konflikt OK OK OK OK konflikt OK OK Matryca kompatybilności metod atrybutów atomowych klas Item i Orders Atrybuty atomowe Get ( ) Put ( ) Get ( ) OK konflikt Put ( ) konflikt konflikt

Transakcje wykonywane w przykładowej bazie danych Rozważanych będzie następujących pięć typów transakcji: T1: realizacja dwóch zamówień na dwa różne produkty dla danego klienta (dwukrotne wywołanie metody ShipOrder dla obiektów i1 i i2, z argumentami o1 i o2); T2: opłacenie przez klienta dwóch zamówień na dwa różne produkty (dwukrotne wywołanie metody PayOrder dla obiektów i1 i i2, z argumentami o1 i o2); T3: sprawdzenie realizacji dwóch zamówień jednego klienta na dwa różne produkty (dwukrotne wywołanie metody TestStatus na zamówieniach o1 i o2 z argumentem shiped); T4: sprawdzenie płatności dwóch zamówień jednego klienta na dwa różne produkty (dwukrotne wywołanie metody TestStatus na zamówieniach o1 i o2 z argumentem paid), T5: obliczenie ogólnej sumy wpłat dla wszystkich zamówień dotyczących danego produktu (wykonanie metody TotalPayment dla produktu i1)

Podstawowy algorytm zarządzania współbieżnością transakcji Synchronizacja współbieżnych transakcji jest realizowana za pomocą algorytmu blokowania dwufazowego stosującego blokady semantyczne związane z poszczególnymi metodami klas Blokady są zwalniane niezależnie przez każdą pod-transakcję Ograniczenia Algorytm podstawowy jest poprawny, jeżeli spełnione są dwa założenia: Wszystkie pary (f, g) potencjalnie konfliktowych metod znajdują się na tym samym poziomie drzewa swoich transakcji Dla każdej pary (f, g ) przodków f i g, które znajdują się na tym samym poziomie drzewa swoich transakcji, f i g operują na tym samym obiekcie

Współbieżne wykonanie dwóch otwartych zagnieżdżonych transakcji T1 T2 ShipOrder(i1,o1) PayOrder(i1,o1) PayOrder(i2,o2) ShipOrder(i2,o2) ChangeStatu Get ChageStatus Put ChangeStatus ChangeStatus Get Put (o1,shipped) (i1,qon) (o1,paid) (i1,qon) (o2,paid) (o2,shipped) (i2,qoh) (i2,ooh) Get (o1,status) Put (o1,status) Get (o1,status) Put (o1,status) Get (o2,status) Put (o2,status) Get (o2,status) Put (o2,status)

Niepoprawna realizacja Ominięcie hermetyczności obiektu Item T1 T3 ShipOrder(i1,o1) ShipOrder(i2,o2) ChangeStat(o1,shipped) Get(i1,QOH) Put(i1,QOH) TestStat(o1,ship) TestStat(o2,ship) ChangeStat(o2,shipped) Get(o1,status) Put(o1,status) Get(o2,status) Get(o2,status) Put(o2,status) Get(o1,status)

Algorytm synchronizacji transakcji w obiektowych bazach danych Struktury pomocnicze Dla każdej blokady l: identyfikator obiektu, na której została założona; lista parametrów aktualnych wywołania metody; identyfikator transakcji / pod-transakcji, która założyła lub czeka na założenie blokady l Dla każdej transakcji / pod-transakcji t: uporządkowana lista wszystkich przodków pod-transakcji t; zbiór wszystkich transakcji / pod-transakcji, które blokują transakcję / pod-transakcję (waits-for-sets)

procedure exec-transaction (t) begin /* faza zakładania blokad */ for all s in tchildren do swaits-for-set := empty for all locks h założonych lub czekających na założenie na obiekcie sobject do b := test-conflict (h, s) if b nil then dodaj b do swaits-for-set fi od if swaits-for-set is not empty then kolejkuj żądanie blokowania sobject; czekaj na zakończenie wszystkich transakcji/pod-transakcji ze zbioru swaits-for-set; fi załóż blokadę na sobject exec-transaction (s) od /* faza akceptacji */ for all s in tchildren do usuń s ze wszystkich waits-for-sets innych transakcji/pod-transakcji if tparent nil then zamień blokadę s na blokadę utrzymaną fi od if tparent = nil then /* koniec transakcji głównej */ zwolnij wszystkie blokady fi end exec-transaction

function test_conflict(h,r) returns tid /* Testuje zgodność metod h i r Dla kompatybilnych blokad zwraca wartość nil Dla niekompatybilnych przodka transakcji h, na którego zakończenie musi czekać transakcja r */ begin if h and r są kompatybilne or r and h należą do tej samej transakcji głównej then return nil fi for all h in hancestor_chain do for all r in rancestor_chain do if h and r są kompatybilne then if h is zatwierdzona then return nil else return h /* r musi czekać na zakończenie h / fi fi od /for all r / od /for all h / return hroot /* w najgorszym przypadku r musi czekać na zakończenie głównej transakcji h */ end test-conflict

Konflikt rozwiązany przez komutatywnych i zatwierdzonych przodków komutatywny i zatwierdzony przodek T 1 T 4 ShipOrder(i1,o1) ShipOrder(i2,o2) ChangeStat(o1,shipped) Get(i1,QOH)Put(i1,QOH) TestStat(o1,paid) TestStat(o2,paid) ChangeStat(o1,shipped) Get(o1,status) Put(o1,status) Get(o1,status) Get(o2,status) Get(o2,status) Put(o2,status)

Konflikt rozwiązany przez komutatywnych i niezatwierdzonych przodków komutatywny i niezatwierdzony przodek ShipOrder(i1,o1) T 1 T 5 TotalPayment(i1) ShipOrder(i2,o2) ChangeStat(o1,shipped) Get(i1,QOH) Put(i1,QOH) ChangeStat(o1,shipped) Get(o1,status) Put(o1,status) Get(o1,status) Get(o1,quantity) Get(o2,status) Put(o2,status) Wykonanie przesunięte w czasie