Obsªuga bª dów w procesach automatycznej konsolidacji rachunków bankowych.

Uniwersytet Warszawski Wydziaª Matematyki, Informatyki i Mechaniki Sebastian Tomaszewski Nr albumu: 219712 Obsªuga bª dów w procesach automatycznej konsolidacji rachunków bankowych. Praca magisterska na kierunku INFORMATYKA Praca wykonana pod kierunkiem dra Piotra Chrz stowskego-wachtla Instytut Informatyki listopad 2009

O±wiadczenie kieruj cego prac Potwierdzam,»e niniejsza praca zostaªa przygotowana pod moim kierunkiem i kwalikuje si do przedstawienia jej w post powaniu o nadanie tytuªu zawodowego. Data Podpis kieruj cego prac O±wiadczenie autora (autorów) pracy wiadom odpowiedzialno±ci prawnej o±wiadczam,»e niniejsza praca dyplomowa zostaªa napisana przeze mnie samodzielnie i nie zawiera tre±ci uzyskanych w sposób niezgodny z obowi zuj cymi przepisami. O±wiadczam równie»,»e przedstawiona praca nie byªa wcze±niej przedmiotem procedur zwi zanych z uzyskaniem tytuªu zawodowego w wy»szej uczelni. O±wiadczam ponadto,»e niniejsza wersja pracy jest identyczna z zaª czon wersj elektroniczn. Data Podpis autora (autorów) pracy

Streszczenie Praca ma na celu przeanalizowanie mechanizmu obsªugi bª dów w systemie Olimpia. Jest to platforma, która pomaga operatorom banku w obsªudze usªug konsolidacji rachunków bankowych (cash pool). Gªówn zalet platformy jest automatyzacja procesów w oferowanych przez bank usªugach. W procesach tych mog zachodzi ró»ne bª dy i aktualnie s one obsªugiwane jedynie w bardzo podstawowy sposób. W swojej pracy zaproponuj usprawnienie tego mechanizmu. W tym celu przedstawi rozwój mechanizmów transakcji oraz dokonam ich porównania. Pozwoli to zapozna si z zagadnieniami transakcyjno±ci oraz lepiej zrozumie zaprojektowany mechanizm, który b dzie na nich bazowaª. Przedstawi równie» dziedzin systemu czyli usªugi cash pool, opisz procesy wykonywane w systemie oraz przeanalizuj aktualn obsªug bª dów. Na koniec przedstawi bª dy aktualnego podej±cia oraz niezb dne modykacje, które poprawi zaimplementowany mechanizm. Sªowa kluczowe bª d, wyj tek, transakcja, dªugotrwaªa, saga, kompensacja, cashpool, Olimpia 11.3 Informatyka Dziedzina pracy (kody wg programu Socrates-Erasmus) J. Computer Applications J.1. Administrative Data Processing J.1.3. Financial Klasykacja tematyczna Tytuª pracy w j zyku angielskim Handling failures in automatic cashpool processing.

Spis tre±ci Wprowadzenie....................................... 7 1. Historia transakcji................................... 9 1.1. Transakcyjno±................................... 9 1.1.1. ACID Atomicy, Consistency, Isolation, Durability.......... 9 1.1.2. Punkt zapisu................................ 13 1.1.3. Transakcje rozproszone........................... 14 1.1.4. Transakcje zagnie»d»one.......................... 18 1.1.5. OLTP.................................... 20 1.2. Dªugotrwaªe zadania................................ 21 1.2.1. L-R..................................... 21 1.2.2. Transakcje ªa«cuchowe........................... 23 1.2.3. Saga..................................... 23 1.2.4. Inne..................................... 27 1.2.5. ACTA.................................... 29 1.3. Wyj tki....................................... 30 1.3.1. Idea..................................... 30 1.3.2. J zyki programowania........................... 30 1.3.3. U»yteczno±................................. 31 1.4. Sieci przepªywu pracy............................... 33 1.4.1. Modele transakcji dla sieci przepªywów.................. 33 1.4.2. Narz dzia.................................. 34 1.5. Usªugi sieciowe................................... 36 1.5.1. Business Process Management(BPM)................... 36 1.5.2. Transakcje.................................. 39 1.5.3. Podsumowanie............................... 42 1.6. Specykacje formalne................................ 43 1.6.1. J zyki modelowania kompensowalnych przepªywów........... 43 1.6.2. Rozszerzenia algebr procesów....................... 43 1.7. Obecny kierunek rozwoju............................. 46 1.7.1. Pami transakcyjna............................ 46 1.7.2. Siatki transakcji.............................. 46 2. Cashpool......................................... 47 2.1. Zarz dzanie pªynno±ci............................... 47 2.2. Zasada dziaªania.................................. 47 2.3. Przykªad....................................... 48 2.4. Sytuacja prawna.................................. 50 3

2.5. Korzy±ci....................................... 50 3. System Olimpia.................................... 51 3.1. System dedykowany................................ 51 3.2. Interfejsy...................................... 52 3.3. Technologia..................................... 53 3.4. Funkcjonalno±ci................................... 54 4. Usªugi w systemie................................... 57 4.1. Usªuga i algorytmy................................. 57 4.2. Wykonywanie usªug................................. 58 4.2.1. Dane..................................... 58 4.2.2. Przetwarzanie danych........................... 59 5. Procesy w systemie.................................. 63 5.1. Idea......................................... 63 5.1.1. Wynik wykonania procesu......................... 64 5.2. Mechanizmy obsªugi bª dów............................ 65 5.2.1. Mechanizmy j zyka Java.......................... 66 5.2.2. Statusy wykonania i przerywanie procesów................ 67 5.2.3. R czna zmiana daty i stanu systemu................... 67 5.2.4. Obsªuga ksi gowa«............................. 67 5.3. Realizacja procesów i obsªuga bª dów....................... 69 5.3.1. Zarz dcaprocesów............................. 69 5.3.2. Proces.................................... 70 5.3.3. Akcja.................................... 71 5.3.4. WykonywaczUsªug............................. 71 5.3.5. Zarz dcausªug............................... 72 5.3.6. Usªuga.................................... 72 5.4. Akcje......................................... 73 5.4.1. Sprawdzenie mo»liwo±ci uruchomienia procesu.............. 73 5.4.2. Synchronizacja danych........................... 73 5.4.3. Przeliczenie warto±ci formuª........................ 73 5.4.4. Operacja: Pobranie sald.......................... 74 5.4.5. Konsolidacja usªug............................. 74 5.4.6. Operacja: Ksi gowanie transakcji konsolidacji.............. 75 5.4.7. Redystrybucja usªug............................ 75 5.4.8. Operacja: Ksi gowanie transakcji redystrybucji............. 75 5.4.9. Naliczenie odsetek bankowych....................... 75 5.4.10. Kapitalizacja odsetek bankowych..................... 76 5.4.11. Ksi gowanie kapitalizacji odsetek bankowych.............. 76 5.4.12. Naliczenie odsetek od wzajemnych zobowi za«............. 76 5.4.13. Kapitalizacja odsetek od wzajemnych zobowi za«............ 76 5.4.14. Ksi gowanie kapitalizacji odsetek od wzajemnych zobowi za«..... 77 5.4.15. Naliczenie opªat............................... 77 5.4.16. Ksi gowanie opªat............................. 77 5.4.17. Wygenerowanie raportów......................... 77 5.4.18. Zmiana daty biznesowej.......................... 77 5.4.19. Zmiana stanu systemu........................... 77 4

6. Ocena........................................... 79 6.1. Braki......................................... 79 6.1.1. Praca na niespójnych danych....................... 79 6.1.2. Niedoko«czone przetwarzanie....................... 79 6.1.3. Bª dne obliczenia.............................. 79 6.1.4. Brak przerwania.............................. 80 6.1.5. Pomini cie usªugi w strukturze wielopoziomowej............ 80 6.2. Rozwi zanie..................................... 80 6.2.1. Przeprojektowanie procesów........................ 81 6.2.2. Rozdzielenie operacji............................ 81 6.2.3. Zmiany akcji................................ 83 6.2.4. Kompensacje................................ 84 6.2.5. R czna kompensacja............................ 85 6.2.6. R czne uruchomienie procesu dla usªugi................. 85 6.2.7. Samoocena................................. 86 7. Podsumowanie..................................... 87 Bibliograa......................................... 89 5

Wprowadzenie A ostatnich latach w polskiej bankowo±ci korporacyjnej du» popularno±ci ciesz si usªugi pªynno±ciowe. Maj one na celu zoptymalizowanie obrotu ±rodkami pieni»nymi na rachunkach bankowych. Pracuj c w rmie Business Management Software byªem wspóªautorem systemu Olimpia, który miaª za zadanie automatyzowanie operacji wykonywanych do tej pory r cznie przez pracowników banku. Przetwarzanie w tym systemie wykonywane jest w automatycznych procesach. W ich trakcie obliczamy niezb dne dane oraz wykorzystujemy odpowiednie systemy bankowe do ksi gowania wygenerowanych transakcji. Podobnie jak we wszystkich systemach informatycznych, jednym z kluczowych wymaga«jest niezawodno±. Procesy w systemie mog wykonywa zªo»one operacje i mog przez to trwa dªugo. Istnieje wiele mo»liwych scenariuszy, które sprawiaj,»e proces nie wykona si poprawnie, np. bª d komunikacji z systemem banku. Z tego powodu wymagane jest, aby proces który wykonuje si automatycznie potraª odpowiednio zareagowa na te zdarzenie. Przez ostatnie kilkadziesi t lat naukowcy i programi±ci zmagali si z problemami niezawodno±ci w swoich systemach. Powstaªy w tym czasie ró»ne narz dzia oraz metody obsªugi bª dów w dªugotrwaªych zadaniach. Niektóre z nich s ogólne, inne za± dedykowane dla konkretnej technologii implementacji. W swojej pracy przedstawi analiz mechanizmu obsªugi bª dów w systemie Olimpia w kontek±cie dotychczasowych odkry. W tym celu przedstawi rozwój mechanizmów transakcji oraz dokonam ich porównania. Pozwoli to zapozna si z zagadnieniami transakcyjno±ci oraz lepiej zrozumie zaprojektowany mechanizm, który b dzie na nich bazowaª. Przedstawi równie» dziedzin systemu czyli usªugi cash pool, opisz procesy wykonywane w systemie oraz przeanalizuj aktualn obsªug bª dów. Na koniec przedstawi bª dy aktualnego podej±cia oraz niezb dne modykacje, które poprawi zaimplementowany mechanizm. Praca jest zorganizowana nast puj co: Rozdziaª 1 porównanie dotychczasowych prac o tematyce transakcyjno±ci. Rozdziaª 2 opis dziedziny systemu, czyli usªugi cash pool. Rozdziaª 3 przedstawienie systemu Olimpia. Rozdziaª 4 zaprezentowanie w jaki sposób traktujemy usªugi w systemie. Rozdziaª 5 dokªadny opis przetwarzania procesów w systemie z analiz obsªugi bª dów. Rozdziaª 6 zaprezentowanie braków i ich mo»liwych rozszerze«. 7

Rozdziaª 1 Historia transakcji Czym jest transakcja? W zasadzie, koncepcja transakcji byªa wynaleziona ju» 6000 lat temu, kiedy Sumerowie zapisywali na glinianych tablicach stan królewskich wªo±ci, w celu badania ich zmian. Ogólnie mówi c, transakcja jest transformacj z jednego stanu w inny. W trakcie tysi cy lat pomysª ten zaadoptowano w wielu innych dziedzinach»ycia, np. w ±wiecie biznesu transakcja jest umow miedzy kupuj cym a sprzedaj cym na wymian towaru i pieni dzy. W okresie rozwoju baz danych na przeªomie lat 60-tych i 70-tych transakcje zawarto w pierwszych urz dzeniach obsªugi transakcji takich jak CICS opracowany przez IBM. W bazach danych rzeczywisty stan ±wiata zewn trznego modeluje si jako relacje i krotki, a transformacje s modykacjami danych. Patrz c z tej perspektywy widzimy transakcje jako grup operacji u»ywanych w celu dost pu albo zmiany bazy danych. Pomimo i» wiedziano,»e atomowo± (patrz sekcja 1.1.1) jest bardzo wa»nym problemem, nie powstaª»aden formalny model a implementacje bazowaªy na reguªach empirycznych. Pierwsza próba formalnego przedstawienia kontroli wspóªbie»no±ci miaªa miejsce w pracy [Eswa76]. Wprowadzaªa ona dwufazowe blokowanie, a pó¹niej staªa si podstaw teorii szeregowalno±ci. Teoria ta jest ci gle fundamentem dzisiejszych rozwi za«zarz dzania wspóªbie»no±ci w bazach danych. W tym samym czasie badano równie» problem odporno±ci na bª dy, który tak»e przedostaª si do ±wiata baz danych. W [Gray78] opisane zostaªy protokoªy DO-UNDO-REDO oraz WAL(ang. write-ahead logging). 1.1. Transakcyjno± 1.1.1. ACID Atomicy, Consistency, Isolation, Durability Transakcje ACID s bardzo wa»ne w informatyce, dlatego mechanizmy te opisano w wielu publikacjach, m. in. [Bern87], [Gray93], [Weik02]. W tym rozdziale nie przeprowadz dogª bnej analizy tej tematyki. Ogranicz si do przedstawienia gªównych zaªo»e«zarz dzania transakcjami w celu opisania idei, która posªu»yªa do dalszego rozwoju mechanizmów transakcyjnych. Atomowo± Wyobra¹my sobie sytuacj kiedy wielow tkowy program korzysta ze wspóªdzielonej pami ci w wieloprocesorowej maszynie. Niskopoziomowe operacje sprz towe takie jak atomowa wymiana 1 s podstawowymi funkcjami, dzi ki którym mo»na konstruowa bardziej zªo»one akcji 1 atomowa wymiana wymiana zawarto±ci rejestru procesora i jednostki pami ci w jednej niepodzielnej 9

mechanizmy synchronizacji. Elementarne operacje maj bardzo proste wªasno±ci, przez co s bardzo wa»ne w programowaniu wspóªbie»nym, gdy» uªatwiaj dowodzenie poprawno±ci i zapewnienie,»e zªo»one operacje z nich konstruowane s zgodne ze specykacj. Zªo»ona operacja jest deniowana jako sekwencja akcji, które mog by zarówno atomowe, jak i zªo»one. Gªówn ide transakcji jest przeniesienie wªasno±ci funkcji skªadowych na ich zªo»enie. Do opisania wyniku akcji, potrzebujemy kilku podstawowych poj. wiat (zwany równie» systemem) skªada si z obiektów, ka»dy z nich ma dobrze zdeniowany stan (zazwyczaj warto±ci zbioru zmiennych). Globalny stan ±wiata jest sum stanów pojedynczych obiektów. Proces jest sekwencj akcji, które s zdeniowane nast puj co: przy danym stanie pocz tkowym systemu oraz podanej ewentualnie warto±ci wej±ciowej, wynikiem wykonywanej samotnie akcji jest sprowadzenie systemu do stanu ko«cowego w sko«czonym czasie oraz ewentualnie dostarczenie wyniku. Dla ka»dej akcji, ko«cowy stan oraz wynik s okre±lone jako funkcja ze stanu pocz tkowego oraz warto±ci wej±ciowej. Caªy model jest w zasadzie maszyn stanow. Wykonania procesów mog ponosi pora»k. Ma to miejsce, gdy zachowanie systemu (albo którego± z jego komponentów) nie speªnia specykacji. Bª dy dzieli si na ró»ne klasy w zale»no±ci od ich wa»no±ci i poziomu zakªócania pracy systemu. Tutaj skupimy si jedynie na bª dach przerywaj cych dziaªanie aplikacji(ang. fail-stop failure): komponent albo dziaªa zgodnie ze specykacj, albo nie dziaªa w ogóle. Teraz dochodzimy do poj cia atomowo±ci, wªasno±ci akcji elementarnych, któr chcemy przenie± równie» na ich zªo»enie. Atomowo± istnieje w dwóch pªaszczyznach: atomowo± wspóªbie»no±ci (ang. concurrency atomicity) We¹my dwie akcje A i B wykonuj ce si niezale»nie we wspóªbie»nych procesach (co oznaczamy jako A B). Je±li»adna nie wykonaªa si bª dnie, to wynik ich dziaªania (przyp. warto±ci wyj±ciowe albo zmiana stanu systemu) jest taki, jak gdyby wykonaªy si po kolei w dowolnej kolejno±ci (A;B albo B;A). Innymi sªowy: zªo»ona operacja przechodzi poprzez stany po±rednie, które s stanami ko«cowymi jej skªadowych. aden z tych stanów nie mo»e by widoczny dla»adnej wspóªbie»nej operacji. Tak przedstawiona atomowo± wspóªbie»na nazywana jest izolacj (ang. isolation). atomowo± awarii (ang. failure atomicity) We¹my akcj A, która wykonana niezale»nie zmienia stan systemu z S1 na S2 (co oznaczamy jako S1 {A} S2). Je±li wyst pi bª d podczas wykonania A stan ko«cowy jest albo S1 albo S2. Oznacza to,»e operacja jest wykonywana w caªo±ci albo wcale. Tak jak poprzednio,»aden stan po±redni nie mo»e by widoczny. Poza bª dami wynikªymi z przyczyn zewn trznych, operacja mo»e zdecydowa o przerwaniu swojego dziaªania i anulowaniu wszystkich wykonanych do tej pory zmian. Tak sytuacj nazwiemy przerwaniem(ang. abort). Je±li S1 {A} S2, to wynikiem przerwania wykonania A jest przywrócenie w systemie stanu S1, co nazywa si odwróceniem(ang. rollback). Dzi ki atomowo±ci bez straty ogólno±ci mo»emy przenie± t sytuacj to wykonania wi kszej liczby wspóªbie»nych operacji. Transakcje w bazach danych Transakcje w przedstawionym znaczeniu zostaªy po raz pierwszy u»yte w systemach zarz dzania bazami danych. Wzbogacono je o dwie dodatkowe cechy: trwaªo± (ang. durability) trwaªo± oznacza,»e je±li transakcja si powiedzie, czyli wykona si bezbª dnie i nie zostanie odwrócona, to zmiany wykonane na bazie s zachowane. Oczywi±cie stan mo»e zosta zmieniony przez kolejne transakcje. Operacja oznaczaj ca 10

pomy±lne zako«czenie transakcji jest nazywana zatwierdzeniem(ang. commit). Trwa- ªo± oznacza,»e kiedy transakcja jest zatwierdzona, zmiany które wykonaªa s odporne na awarie. Wyª czamy jednak katastrofy, czyli rzadkie zdarzenia, które mog skutkowa uszkodzeniem sprz tu i utrat danych. spójno± (ang. consistency) spójno± w bazach danych jest wyra»ana zazwyczaj jako zbiór ogranicze«integralno±ci, np. predykatów okre±lanych na jej stanie. Te ograniczenia odzwierciedlaj wªasno±ci rzeczywistych obiektów reprezentowanych przez baz danych (konta bankowe, zawarto± biblioteki). Poniewa» wymagamy spójno±ci podczas caªego»ycia bazy danych, transakcja przeprowadza system z jednego spójnego stanu w inny spójny stan. Podczas wykonania, niektóre po±rednie stany mog by niespójne, ale, dzi ki izolacji, nigdy nie s widoczne. Spójno± jest okre±lana poprzez wymogi konkretnej aplikacji, dlatego cz sto same mechanizmy bazodanowe s niewystarczaj ce i odpowiedzialno±ci programisty jest pisanie kodu, który zachowa stan danych spójnym w szerszym zakresie. Wªasno±ci ACID(ang. Atomicy, Consistency, Isolation, Durability) zostaªy przedstawione we wczesnych latach 80-tych (patrz poz. [Gray81]). Przegl d wczesnych technik odtwarzania danych znajduje si w [Haer83]. Wszystkie te poj cia znalazªy zastosowane przy projektowaniu wielu systemów zarz dzania bazami danych, w tym przeªomowego System-R, który jako pierwszy wykorzystywaª j zyk zapyta«sql i byª dowodem na to,»e relacyjne bazy danych potra by wydajne (patrz poz. [GMBL81]). Powy»sze wªa±ciwo±ci uj to w matematycznej teorii szeregowalno±ci. Transakcje ACID odniosªy wielki sukces, gdy» dzi ki swoim cechom zapewniaªy,»e stan systemu jest spójny nawet w przypadku bª dów oraz nietypowych zdarze«, pomimo wspóªbie»nego wykonywania zada«. Za swoj prac i wkªad w rozwój informatyki Jim Gray otrzymaª Nagrod Turinga w roku 1998. Mechanizm dziaªania Transakcje sprzyjaj rozdzieleniu koncepcji. Pozwalaj programistom skoncentrowa si na logice aplikacji (m. in. dbaniu o spójno± danych biznesowych), podczas kiedy system zarz dzania transakcjami (inaczej zarz dca transakcji) odpowiada za zapewnienie pozostaªych wªasno±ci transakcji (atomowo±, izolacja i trwaªo± ). Sªu» do tego nast puj ce mechanizmy (patrz poz. [Lewi02]): Izolacj zapewnia kontrola wspóªbie»no±ci, podstawowym mechanizmem jest tu blokowanie obiektów. System zarz dzania baz danych zakªada blokady na odpowiednich obiektach, kiedy programy z nich korzystaj. Blokady s utrzymywane dopóki transakcja si nie zako«czy, zapobiegaj c przed odczytem niespójnych danych przez wspóªbie»ne transakcje w czasie trwania niesko«czonej transakcji. Inna technik kontroli wspóªbie»- no±ci jest stemplowanie obiektów datami systemowymi i zarz dzanie dost pem poprzez kontrol stempli. Wi cej informacji w [Rama97]. Atomowo± jest zapewniana przez odzyskiwanie(ang. recovery), które wykorzystuje mechanizmy logowania. Ka»da modykacja bazy danych jest zapisywana w tabeli loguj cej przechowywanej niezale»nie od samych danych. Odwrócenie mo»e si wykonywa przez przywrócenie poprzednich warto±ci ka»dego obiektu znalezionego w logu. Trwaªo± zale»y od atomowo±ci awarii i opiera si na wykorzystaniu trwaªego magazynu danych(ang. stable storage). Jest to mechanizm gwarantuj cy,»e zapisane w 11

nim dane s odporne na uszkodzenia (wykluczaj c katastrofy). Techniki implementacji takich mechanizmów zostaªy opisane w [Lamp79]. Podobnie jak w tracie odwracania, po awarii aktualny stan mo»e by odtworzony na podstawie logu. Zauwa»my,»e blokowanie jest niezb dne, aby logowanie dziaªaªo prawidªowo. Je±li kilka czynno±ci zmodykowaªo ten sam obiekt w tym samym czasie, to nie byªoby wiadome który stan powinien zosta odtworzony, gdyby jedna z operacji wymagaªa cofni cia. Programowanie System zarz dzania transakcjami udost pnia swoim u»ytkownikom prosty interfejs. Skªadnia operacji mo»e si ró»ni w zale»no±ci od systemu, ale podstawowy interfejs zazwyczaj skªada si z nast puj cych funkcji: begin transaction rozpocz cie nowej transakcji. commit transaction poprawne zako«czenie transakcji (zmiany zostaj trwale zapisane). abort/rollback transaction przerwanie wykonania transakcji i anulowanie zmian wykonanych od jej rozpocz cia do tego momentu. Powy»sze operacje sªu» do rozgraniczania zasi gu transakcji, czyli rozdzielenia operacji b d cych cz ±ci transakcji. Granice mog by dokªadnie okre±lone przez programist, b d¹ automatycznie wygenerowane na podstawie deklaracji w ±rodowisku programowania. Kluczowe znaczenie ma fakt,»e mechanizmy ACID powalaj caªkowicie ukry przed programist zarówno bª dy jak i przeploty 2. Mo»e on po prostu pisa kod wykonuj cy wa»ne operacje biznesowe oraz opakowywa kod w konstrukcj transakcyjn. System zapewni to,»e program zawsze wykona si jakby byª jedyn i niepodzieln jednostk pracy(ang. unit of work) caªkowicie niezale»nie od innych akcji, które mog dziaªa wspóªbie»nie z jego wykonaniem. Je±li operacja zako«czy si z powodzeniem, to zarz dca transakcji zapewni zapisanie zmian w bazie danych pomimo mo»liwych bª dów kolejnych transakcji. Gdy jednak wykonaªa si cz ± pracy, ale bª d powstrzymaª program przed zako«czeniem, wówczas system wykona odwrócenie niesko«czonej akcji, czyli przywróci dane do stanu sprzed rozpocz cia operacji. Ograniczenia W rzeczywisto±ci istniej bardziej ogólne wªa±ciwo±ci ni» ACID: VCRP(ang. Visibility, Consistency, Recovery, Permanence), które mog sªu»y jako warunki oceny modelu transakcji (patrz poz. [Warn93]): Widoczno± (ang. visibility) okre±la mo»liwo± dost pu do wyników wykonywanej transakcji przez inne transakcje. Spójno± (ang. consistency) odnosi si do poprawno±ci stanu bazy danych po zatwierdzeniu transakcji. Odzyskiwalno± (ang. recovery) oznacza zdolno± do przywrócenia bazy danych do poprzedniego poprawnego stanu w przypadku napotkania bª du. 2 przeplot wspóªbie»ne wykonanie dwóch lub wi cej sekwencji transakcji, w których poszczególne transakcje jednej sekwencji mog wykonywa si naprzemiennie z transakcjami z innych sekwencji 12

Trwaªo± (ang. permanence) to mo»liwo± zmiany stanu bazy danych przez zatwierdzon transakcj bez straty wyniku pomimo awarii. Je±li u»yjemy miary VCRP do oceny standardowego modelu transakcji (zwanego równie» pªaskim), to otrzymujemy wªasno±ci ACID, które s podstaw tych stosunkowo prostych transakcji. Okazaªy si one bardzo u»yteczne w tradycyjnych aplikacjach bazodanowych, gdzie czas wykonania jest krótki, ilo± wspóªbie»nych transakcji jest maªa a system baz danych znajduje si na jednym serwerze. To co kiedy± byªo du» zalet, okazaªo si sporym ograniczeniem dla aplikacji, które wymagaj wspóªpracuj cych wspóªbie»nych aktywno±ci, operuj na kilku bazach danych lub mog po prostu trwa dªugo. Aby temu zaradzi, zacz to tworzy rozszerzone modele transakcji, które miaªy by bardziej elastyczne i przezwyci»a te ograniczenia. 1.1.2. Punkt zapisu Punkt zapisu lub inaczej punkt po±redni(ang. save point) przedstawiono po raz pierwszy w [Astr76] jako mechanizm umo»liwiaj cy wykonywanie cz ±ciowego odwracania. Pozwala on na oznaczenie pewnego miejsca w transakcji jako specjalnego momentu jej wykonania i nazwanie go. W jednej transakcji mo»e istnie wiele punktów zapisu. W ka»dym punkcie po±rednim, zapami tywane s dane przechowuj ce stan kontekstu bazy danych u»ywanego przez transakcje. Kiedy transakcja si nie powiedzie, mo»e odtworzy stan do okre±lonego punktu zapisu przywracaj c kontekst i zwalniaj c blokady obiektów zaªo»one podczas wykonania od tego punktu. Mechanizm ten jest bardzo u»yteczny przy implementacji zªo»onej obsªugi bª dów w aplikacjach bazodanowych je±li bª d wyst pi w ±rodku transakcji wykonuj cej wiele operacji, to mo»e si ona cofn do podanego punktu zapisu bez konieczno±ci anulowania caªej transakcji. Wykorzystanie punktów zapisu przy odwracaniu nie jest jednak proste i wymaga dobrego przemy±lenia, poniewa»: po cofni ciu si do punktu zapisu i odtworzeniu transakcja kontynuuje przetwarzanie a» si zako«czy, w przeciwie«stwie do anulowania, gdzie po przywróceniu stanu wykonanie zostaje przerwane, pomimo odtworzenia stanu bazy danych do podanego puntu zapisu, warto±ci lokalnych zmiennych transakcji nie s cofane, co oznacza,»e transakcja musi kontynuowa prac w inny sposób ni» planowano pierwotnie, po odtworzeniu punktu zapisu, usuni te zostaj punkty zapisu utworzone od punktu do którego przywracamy do miejsca wywoªania przywrócenia. Mechanizm punktów zapisu mo»na u»y z prostymi pªaskimi transakcjami ACID. Jednak wi ksz rol odegraª on w rozwoju zaawansowanych modeli transakcji: rozproszonych, zagnie»d»onych, ªa«cuchowych, itd. Modele te byªy dedykowane do okre±lonego typu aplikacji biznesowych i s przykªadem zastosowania mechanizmu punktu zapisu do rozwi zania ró»nych problemów. Punkty bezpiecze«stwa s opisane w standardzie SQL oraz s wspierane w pewnej formie w niektórych bazach danych: PostgreSQL, Oracle, Microsoft SQL Server, MySQL, DB2, SQLite (od 3.6.8), Firebird and Informix (od 11.50xC3). 13

1.1.3. Transakcje rozproszone Do tej pory zakªadali±my,»e transakcja wykonuje si na jednej bazie danych. Wraz z rozwojem potrzeb i technologii powstaªo wymaganie, aby wykonywa transakcje na obiektach, które mog znajdowa si w ró»nych systemach baz danych dost pnych przez sie. Zarz dzanie transakcjami w rozproszonym systemie opiera si na wspóªpracy lokalnych systemów zarz dzania transakcjami. Aby zachowa globaln spójno±, zarz dcy musz u»ywa wspólnego protokoªu uzgadniania. Gªównym przedmiotem uzgodnienia jest wspólna decyzja, kiedy wykona zapisanie a kiedy anulowanie transakcji. Decyzja musi by spójna pomi dzy wszystkimi uczestnikami transakcji. Oznacza to,»e rozproszony zapis powinien by atomowy (wszyscy albo nikt). Jest to gªówny problem przy transakcjach rozproszonych i w tej sekcji przedstawi najwa»niejsze pomysªy na jego rozwi zanie. Warto doda,»e protokóª, który mo»e by u»yty do uzgadniania zapisu transakcji, mo»e by równie» u»yty do zarz dzania wspóªbie»no±ci transakcji poprzez tzn. porz dkowanie zapisu (patrz poz. [Raz92]). Atomowe zapisywanie Przyjrzymy si na pocz tku wªasno±ciom, które powinien speªnia poprawny protokóª zatwierdzania rozproszonych transakcji. W rozproszonym systemie zarz dzania transakcjami lokalny proces kontroluje prace lokalnego zarz dcy i obsªuguje komunikacj z podobnymi procesami w innych w zªach sieci. Zakªadamy,»e: ª czno± jest rzetelna, czyli wiadomo±ci nie s zmieniane w trakcie dostarczania, oraz równoczesna, czyli»aden w zeª nie b dzie znacz co spó»niony i mo»na przyj górne ograniczenie na czas odpowiedzi. Dodatkowo zakªadamy,»e bª dy poª czenia lub samych procesów nie rozdziel sieci. procesy mog napotyka bª dy. W takiej sytuacji procesy przestaj wykonywa operacje, nie wykonuj nieprawidªowych operacji oraz nie zapominj swojego stanu. Poprawny proces to taki, który zawsze si powodzi. ka»dy w zeª posiada trwaªy magazyn danych (tak jak przy transakcjach ACID, rozdziaª 1.1.1). Zaªo»enie o rzetelno±ci i równoczesno±ci ª czno±ci jest potrzebne, aby zapewni,»e uzgodnienie przy u»yciu protokoªu wykona si w sko«czonym czasie. Transakcja ko«czy si, kiedy którykolwiek proces uczestnicz cy w transakcji wy±le» danie zatwierdzenia b d¹ anulowania transakcji. W tym momencie rozpoczyna si uzgadnianie, w którym ka»dy uczestnik mo»e odda gªos czy jest gotowy do wykonania lokalnego zapisu czy nie. Aby transakcja zostaªa zatwierdzona, ka»dy proces musi chcie zatwierdzenia, w przeciwnym przypadku transakcja musi by przerwana. Przed» daniem zatwierdzenia, którykolwiek z uczestników mo»e spontanicznie (nie sugeruj c si wspóln decyzj ) zdecydowa,»e anuluje swoj cz ± transakcji. Podstawowym wymaganiem dla ka»dego protokoªu jest to, aby wszystkie procesy byªy zgodne, co do tego czy transakcja jest zatwierdzona, czy anulowana. Ka»dy proces zaczyna w stanie pracuj cy (patrz rys. 1.1), w którym mo»e zdecydowa, czy chce zatwierdzi, czy anulowa transakcj. Anulowanie skutkuje prostym przej±ciem do stanu anulowany. Je±li za± zdecyduje,»e chce zapisa, to przechodzi do stanu gotowy, a nast pnie do stanu zatwierdzony. Celem protokoªu jest to, aby wszystkie procesy osi gn ªy stan zatwierdzony b d¹ wszystkie osi gn ªy stan anulowany. Transakcja mo»e zosta zatwierdzona, wtedy i tylko wtedy gdy wszystkie procesy s w stanie zatwierdzony. Poprawny protokóª powinien dopuszcza jedynie nast puj ce zmiany stanów: 14

Rysunek 1.1: Stany procesów w rozproszonej transakcji. proces mo»e zmieni stan z pracuj cy na gotowy. je±li proces jest w stanie gotowy oraz wszystkie procesy s w stanie gotowy albo zatwierdzony, to proces mo»e zmieni stan na zatwierdzony. je±li proces jest w stanie pracuj cy albo gotowy oraz»aden proces nie jest w stanie zatwierdzony, to proces mo»e zmieni stan na anulowany. gdy jeden proces wejdzie do stanu zatwierdzony b d¹ anulowany, wówczas zostaje tam na zawsze. Te wªasno±ci skutkuj tym,»e kiedy jaki± proces wejdzie do stanu zatwierdzony,»aden inny proces nie mo»e wej± do stanu anulowany, i odwrotnie. Implikuj one równie»,»e transakcja mo»e zosta zatwierdzona jedynie w nast puj cym scenariuszu: 1. wszystkie procesy weszªy do stanu gotowy, w dowolnej kolejno±ci 2. wszystkie procesy weszªy do stanu zatwierdzony, w dowolnej kolejno±ci Osi gni cie celu algorytmu nie jest proste w modelu, w którym procesy mog napotyka bª dy b d¹ zosta odizolowane przez bª d komunikacji. Trywialnym rozwi zaniem jest to, aby ka»dy proces zawsze przechodziª do stanu anulowany, ale taki protokóª nigdy nie doprowadzi do zatwierdzenia transakcji, wi c jest bezu»yteczny. Dodatkowo z twierdzenia [Fisc85] wynika,»e deterministyczny, czysto asynchroniczny algorytm nie mo»e jednocze±nie speªnia postawionych wymaga«oraz gwarantowa uzgodnienia zatwierdzenia transakcji w sytuacji napotkania bª dów. Dlatego wymagania»ywotno±ci dla protokoªu s okre±lone nast puj co: nietrywialno± je±li caªa sie jest bezbª dna podczas wykonania algorytmu, wtedy: a) je±li wszystkie procesy osi gn stan gotowy, to wszystkie osi gn stan zatwierdzony; b) je±li który± proces osi gnie stan anulowany, to wszystkie procesy osi gn stan anulowany nieblokowalno± je±li przez caªy czas wystarczaj co du»y fragment sieci w zªów jest bezbª dny wystarczaj co dªugo 3, to wszystkie procesy wykonywane w tych w zªach osi gn zgodnie stan zatwierdzony, b d¹ anulowany. Dwufazowe zatwierdzanie Dwufazowy protokóª zatwierdzania, w skrócie 2PC(ang. two-phase commit), zostaª zaproponowany w pracy [Gray78]. Wspóln decyzj podejmuje koordynator, który jest jednym z uczestników transakcji. 3 zale»y od czasu odpowiedzi poprawnych procesów oraz pr dko±ci sieci 15

Rysunek 1.2: Uzgadnianie w 2PC. Protokóª zaczyna si, kiedy jaki± proces wejdzie do stanu gotowy i prze±le komunikat do koordynatora(patrz rys. 1.2). Po otrzymaniu wiadomo±ci koordynator sam przechodzi do stanu gotowy i wysyªa komunikat przygotuj si do wszystkich innych procesów. Po otrzymaniu wiadomo±ci, ka»dy uczestnik, który ci gle przebywa w stanie pracuj cy, mo»e zmieni stan na gotowy i wysªa komunikat. Kiedy koordynator otrzyma wiadomo± gotowy od wszystkich procesów, mo»e wej± do stanu zatwierdzony i poinformowa uczestników, którzy po otrzymaniu wiadomo±ci zatwierd¹ mog równie» wej± do stanu zatwierdzony. Rysunek 1.2 jest uproszczony. Wiadomo± od koordynatora o konieczno±ci przygotowania jest sugesti,»e je±li który± proces jeszcze tego nie zrobiª, to wªa±nie nastaª odpowiedni moment. W rzeczywisto±ci ka»dy proces mo»e w dowolnej chwili wej± do stanu gotowy i wysªa komunikat. Jest to równoznaczne z jego odpowiedzi na komunikat koordynatora o przygotowaniu si. Ka»dy proces mo»e spontanicznie wej± do stanu anulowany je±li byª w stanie pracuj cy, a koordynator mo»e wej± do stanu anulowany, je±li nie byª w stanie zatwierdzony. Kiedy koordynator anuluje transakcje, wysyªa informacje do wszystkich procesów, które po otrzymaniu wiadomo±ci zmieniaj stan na anulowany Bª dy W protokole zatwierdzania transakcji, je±li jeden b d¹ wi cej procesów napotka bª d, transakcja zazwyczaj jest przerywana. W 2PC, je±li koordynator nie otrzyma wiadomo±ci o gotowo±ci od którego± uczestnika wystarczaj co szybko, anuluje transakcje i informuje o tym pozostaªe procesy. Zauwa»my,»e bª d koordynatora mo»e spowodowa zablokowanie protokoªu zanim koordynator zostanie naprawiony, b d¹ wybrany nowy. W szczególno±ci, gdy bª d nast pi po tym jak wszyscy uczestnicy potwierdzili przej±cie do stanu gotowy, wówczas»aden z nich nie jest w stanie stwierdzi czy koordynator zatwierdziª czy anulowaª transakcj. Nieblokuj cy protokóª zatwierdzania to taki, w którym bª d jednego procesu nie stoi na przeszkodzie w zdecydowaniu przez pozostaªe czy transakcja jest zapisana czy anulowana. Powstaªo kilka takich protokoªów, a cz ± z nich zostaªa zaimplementowana. Ich autorzy próbuj zazwyczaj naprawi 2PC poprzez wybór innego koordynatora w sytuacji wyst pienia bª du u aktualnego. Jednak»aden z nich nie proponuje kompletnego algorytmu, który za- 16

pewni wszystkie wymagania poprawno±ci. Dla przykªadu, w bardzo znanej publikacji na temat nieblokuj cego zatwierdzania [Bern87] brakuje wyja±nienia co proces powinien zrobi, je±li otrzyma wiadomo±ci od dwóch innych procesów, twierdz cych,»e s koordynatorem. Zapewnienie,»e taka sytuacja nie nast pi jest problemem równie trudnym jak implementacja protokoªu zatwierdzania transakcji. Inne podej±cie zostaªo zaprezentowane w pracy [Gray06]. Autorzy prezentuj Paxus Commit protokóª, który u»ywa wielu koordynatorów i jest nieblokuj cy, je±li wi kszo± z nich pracuje. Idea algorytmu wywodzi si od problemu jednomy±lno±ci w programowaniu rozproszonym, dotyczy on zbioru procesów uzgodniaj cych pewn warto± (patrz poz. [Dwor88]). Rozwi zaniem jest algorytm asynchroniczny Paxos (patrz poz. [DePr97]). Z jego wykorzystaniem autorzy skonstruowali protokóª zatwierdzania transakcji, a 2PC okazuje si jego zdegenerowanym przypadkiem u»ywaj cym jednego koordynatora, nieblokuj cym si je±li ten pracuje. W teorii systemów rozproszonych istniej wyniki wskazuj ce,»e zatwierdzanie transakcji jest trudniejsze ni» problem jednomy±lno±ci (patrz poz. [Guer95]). Bazuj one jednak na silniejszej denicji zatwierdzania transakcji. Mówi ona,»e transakcja powinna by zatwierdzona, je±li wszyscy uczestnicy s bezbª dni i weszli do stanu gotowy, nawet je±li wyst piªy nieprzewidywalne opó¹nienia poª czenia. Jednak zaªo»yli±my na pocz tku,»e wymaganie nietrywialno±ci, musi by speªnione jedynie przy dodatkowym warunku nieblokowalno±ci, czyli, odwrotnie w stosunku do silniejszej denicji, wszystkie wiadomo±ci s dostarczane w jakim± znanym limicie czasu. Silniejsza denicja zatwierdzania transakcji nie jest implementowalna w typowych systemach transakcyjnych, je±li przypadkowe opó¹nienia musz by tolerowane. Narz dzia Pierwsze rozproszone bazy danych powstaªy na pocz tku lat 80-tych. System R* (patrz poz. [Moha86]) byª rozproszonym rozszerzeniem Systemu-R. Inne wpªywowe systemy transakcyjne to: Camelot, pó¹niej znany jako Encina (patrz poz. [Eppi91]) oraz UNITS (Unix Transaction System), pó¹niej znany jako Tuxedo (patrz poz. [Andr96]). Zarówno Encina jak i Tuxedo staªy si produktami, które s u»ywane do dzi±. Najbardziej wpªywowy na rozwój rozproszonych transakcji byª model X/Open Distributed Transaction Processing (X/Open DTP)(patrz poz. [XOpen96]). Jest to architektura programistyczna zapewniaj ca wielu aplikacjom dost p do wspóªdzielonych zasobów udost pnianych przez wielu zarz dców zasobów (np. bazy danych) i pozwalaj ca, aby ich praca byªa koordynowana poprzez globaln transakcj. Model X/Open DTP jest uwa»any jako referencyjna implementacja protokoªu 2PC. 17

1.1.4. Transakcje zagnie»d»one Koncepcja transakcji zagnie»d»onych zaprezentowano w [Moss85]. Motywacj do jej powstania byªo umo»liwienie wspóªbie»no±ci w obr bie transakcji oraz potrzeba wi kszej ziarnisto±ci przy deniowaniu atomowo±ci. Pomysª polega na tym, aby transakcja skªadaªa si z podtransakcji w hierarchiczny sposób tworz c drzewo podtransakcji. Podstawowymi poj ciami s : korze«gªówna transakcja li± podtransakcja nie posiadaj ca wªasnych podtransakcji dziecko podtransakcja z poziomu o 1 ni»szego potomek podtransakcja z dowolnego ni»szego poziomu rodzic nadtransakcja z poziomu o 1 wy»szego przodek nadtransakcja z dowolnego wy»szego poziomu Ka»da podtransakcja mo»e skªada si z kolejnych podtransakcji, lecz tylko li±cie wykonuj operacje na bazie danych. Pozostaªe transakcje w strukturze funkcjonuj jako koordynatorzy. Korze«sªu»y jako granica obejmuj ca wszystkie cz stkowe podtransakcje oraz posiada wszystkie wªasno±ci tradycyjnej transakcji ACID. Caªe drzewo transakcji jest atomowe, szeregowalne oraz odizolowane od innych drzew (transakcji zagnie»d»onych). Dziecko mo»e si rozpocz dopiero po rozpocz ciu si rodzica, a rodzic mo»e zosta zatwierdzony dopiero kiedy wszystkie jego dzieci zostan zako«czone. Ka»da podtransakcja jest atomowa, wi c mo»e zosta anulowana niezale»nie od swojego rodzica. W drzewiastej strukturze mo»liwe jest wspóªbie»ne wykonywanie podtransakcji, o ile nie blokuj si one wzajemnie. Je±li transakcja jest przerywana, wszyscy jej potomkowie musz zosta przerwani. W przypadku, gdy niektóre zostaªy ju» zatwierdzone, zmiany musz zosta wycofane tak, jakby podtransakcje nie zostaªy wykonane. Je±li anulowanie nast piªo w podtransakcji (±wiadomie lub przez bª d), rodzic nie musi automatycznie wykonywa anulowania. Mo»e spróbowa wykona akcje ratunkow : 1. powtórzy podtransakcj, je±li jest prawdopodobie«stwo,»e si powiedzie 2. uruchomi awaryjn podtransakcj do wykonania alternatywnych kroków 3. przerwa, je±li»aden z powy»szych nie mo»e zosta wykonany Dokªadniejszy opis mechanizmów odzyskiwania w transakcjach zagnie»d»onych mo»na znale¹ w [WarRee93]. Kiedy jednak podtransakcja si powiedzie i zatwierdzi, wszystkie zasoby do których miaªa dost p s automatycznie dziedziczone przez rodzica, aby ten mógª przekaza je do kolejnych podtransakcji, b d¹ do rodzica kiedy sam zostanie zatwierdzony. Konikty w dost pie do zasobów mog zaistnie jedynie przy podtransakcjach znajduj cych si w innych gaª ziach drzewa. Korzy±ci Transakcje zagnie»d»one posiadaj trzy gªówne zalety: modularyzacja ka»d skomplikowan transakcj mo»na rozªo»y na proste podtransakcje tworz ce hierarchi 18

odtwarzalno± mo»liwo± implementowania odtwarzania na bardziej szczegóªowym poziomie (podtransakcje, a nie caª gªówna transakcja) wspóªbie»no± kontrolowane wspóªbie»ne wykonanie bezkoniktowych podtransakcji Ten model zapewnia osªabione wªasno±ci ACID korze«posiada tradycyjne wªasno±ci, podtransakcje gwarantuj jedynie atomowo± i izolacj. Podsumowuj c wªasno±ci tego modelu: Ka»de dziecko widzi cz ±ciowe wyniki swoich przodków, oraz wyniki wszystkich innych zatwierdzonych transakcji. Przy zatwierdzeniach podtransakcji stan bazy danych ulega zmianie przez co dane mog nie by spójne, mimo,»e ko«cowy wynik gªównej transakcji mo»e by spójny. Dziecko mo»e utrwali swój wynik w systemie dopiero kiedy rodzic zostanie zatwierdzony. Dopiero zatwierdzenie gªównej transakcji skutkuje zapisaniem danych do systemu. Atomowo± dotyczy ka»dej podtransakcji niezale»nie. Niepowodzenie jednej z nich nie oznacza przerwania rodzica. Dalszy rozwój Idea transakcji zagnie»d»onych przyj ªa si bardzo dobrze, a w pó¹niejszych latach bazowaªy na niej inne modele. W [Weik92] autorzy przedstawili transakcje wielopoziomowe (warstwowe) oraz ich uogólnienie: otwarte transakcje zagnie»d»one. Gªówne zmiany w modelu to (wi cej w poz. [Lewi02]): ka»dej transakcji w drzewie przypisany zostaje poziom w zale»no±ci od architektury systemu. Wszystkie li±cie znajduj si na jednym najni»szym poziomie. podtransakcje wykonuj si sekwencyjnie, a nie wspóªbie»nie. udost pnienie operacji przedzatwierdzenie(ang. pre-commit), która pozwala na zatwierdzenie i utrwalenie podtransakcji przed zatwierdzeniem rodzica. Oznacza to,»e zmiany nie s mo»liwe do odwrócenia w tradycyjny sposób. Kiedy rodzic wykonuje odwrócenie, musi u»y specjalnej transakcji kompensacji, która musi semantycznie odwróci zmiany, a nie po prostu przywróci stan (wi cej o kompensacjach przy omówieniu Sag, rozdziaª 1.2.3). Otwarte transakcje zagnie»d»one ró»ni si od powy»szego modelu tym,»e struktura drzewa nie jest ju» ograniczona do warstw i li±cie mog znajdowa si na ró»nych poziomach. Tradycyjne zagnie»d»one transakcje zapewniaj izolacj na globalnym poziomie, po±rednie wyniki zatwierdzonych podtransakcji nie s widoczne dla wspóªbie»nie wykonywanych podtransakcji. W nowym modelu izolacja zostaje osªabiona, w celu zwi kszenia wspóªbie»no±ci. Transakcje zagnie»d»one s modelem o du»ej sile wyrazu i s powi zane z koncepcj modularyzacji w in»ynierii oprogramowania (patrz poz. [Gray93]). 19

1.1.5. OLTP Wi kszo± komercyjnych systemów niededykowanych baz danych u»ywa wy»ej wymienionych mechanizmów, które optymalizowano do wykonywania operacji biznesowych typowych w latach 80-tych i 90-tych. Funkcjonalno± byªa do± prosta, np. zapisanie zamówienia w magazynie, b d¹ wpªaty w banku. Aplikacje tego typu (zwane OLTP) byªy chlebem powszednim w przedsi biorstwach w tamtych czasach. Jednak»e od kilkunastu lat, wraz z rozwojem Internetu, mechanizmy te okazaªy si niewystarczaj ce do nowych wymaga«biznesowych takich jak integracja aplikacji przedsi biorstwa(ang. EAI) oraz integracji przedsi biorstwoprzedsi biorstwo(ang. B2Bi). Nowe aplikacje wyró»nia jedna wa»na cecha: dziaªania(aktywno±ci), które s przez nie automatyzowane trwaj dªugo (od kilku sekund nawet do kilku miesi cy), poniewa» opieraj si na wspóªpracy wielu uczestników oraz cz sto wymagaj interakcji z czªowiekiem. Blokowanie danych na tak dªugi czas jest nieefektywne, gdy» mo»e opó¹ni inne wspóªbie»ne zadania na kilka dni b d¹ dªu»ej. Innym ograniczeniem aplikacji OLTP jest to,»e transakcje oddziaªuj w ramach jednej spójnej jednostki kontroli 4. W przeciwie«stwie do starego modelu, nowoczesne aplikacje dla przedsi biorstw ªami te reguªy, np. jeden proces mo»e anga»owa magazyn, oddziaª logistyczny oraz ksi gowo±. W B2Bi proces cz sto wymaga uczestnictwa ró»nych rm, które mog by wspóªpracownikami jak i konkurencj. Tutaj blokowanie obiektów staje si niedopuszczalne a przewa»nie nieosi galne, gdy»»adne przedsi biorstwo nie pozwoli swojej konkurencji na zablokowanie wªasnych danych. Daje to bardzo ªatw mo»liwo± wykonywania ataków odmowy usªugi(ang. Denial of Service). 4 na pojedynczej bazie danych, pó¹niej rozproszone na kilka instancji, ale zarz dzanych przez jeden system zarz dzania 20

1.2. Dªugotrwaªe zadania 1.2.1. L-R Dªogotrwaªy Aby zrozumie koncepcj dªugotrwaªych (ang. L-R - long-running) transakcji, zwró my uwag na ich czas»ycia. Dªugo±»ycia transakcji okre±lmy jako minimaln ilo± czasu przez jaki transakcja jest otwarta. Transakcja krótkotrwaªa mo»e zacz si i zako«czy w ci gu kilku sekund. Dªugotrwaªa za± mo»e»y przez minuty, godziny a nawet dni, w zale»no±ci od wymaga«biznesowych i u»ytych technologii. Dodatkowo, ka»da transakcja otwierana na niezdeniowany okres czasu równie» kwalikuje si do miana dªugotrwaªej. Krótkotrwaªe transakcje s ªatwe do obsªu»enia, poniewa», by zachowa wªasno±ci ACID, zasoby przez nie u»ywane mog by po prostu zablokowane na caªy czas trwania. Podobna strategia nie mo»e by zastosowana przy dªugotrwaªych transakcjach. Blokowanie zasobów na dªugi czas mo»e powa»nie zmniejsza wydajno± aplikacji z powodu dªugich czasów oczekiwania oraz zakleszczenia(ang. deadlock). Z dªugotrwaªymi transakcjami mamy doczynienia m.in.: kiedy wykonujemy transakcj z ogromn ilo±ci zapyta«, gdzie bª d jednego z nich mo»e spowodowa bª d caªej transakcji, który b dzie wymagaª odwrócenia do ostatnio zapisanego stanu bazy danych. Taki scenariusz mo»e mie miejsce równie» przy pracy na kilku bazach danych. przy przetwarzaniu wsadowym (ang. batch processing), które zazwyczaj wykonuje si dªugo, zazwyczaj kilka godzin, np. regularna kopia wa»nych danych. W wi kszo±ci przypadków taki proces wykonuje jedynie odczyt danych ¹ródªowych, wi c bªedy nie powinny wyst pi. Lecz w tych rzadkich przypadkach, kiedy dochodzi do modykacji danych, bª d b dzie skutkowaª równie dªugim procesem odwracania. w czasie pseudoasynchronicznych aktywno±ci u»ywaj cych transakcji. S one cz sto wykorzystywane we wspóªbie»nych zadaniach przy komunikacji. Obsªuga odwracania jest bardzo skomplikowana, gdy» mo»e wymaga obsªu»enia niezale»nych, czasami nieznaj cych si procesów (wi cej przy transakcjach usªug sieciowych, rozdziaª 1.5.2). Dlaczego nie transakcje Dªugotrwaªe transakcje s cz sto u»ywane do modelowania rzeczywistych transakcji biznesowych. Samo poj cie transakcji cz sto kojarzy si z transakcjami ACID. Dªugotrwaªe transakcje maj inna semantyk oraz mechanizmy dziaªania, np. rzadziej korzystaj z blokad. W wielu publikacjach jako przykªad prezentuj cy dªugotrwaª transakcj przedstawiane jest organizowanie podró»y. Przyjrzyjmy si takiemu wariantowi: 1. Decyduj si na podró» do Hiszpanii za dwa miesi ce i zamawiam bilet lotniczy i miejsce w hotelu. 2. Hotel, w którym mam rezerwacj, osi ga pewien próg go±ci, powy»ej którego postanawia zwi kszy zatrudnienie na ten okres oraz zamówi wi cej jedzenia. 3. Zamówienie zostaje wysªane do hurtowni. 4. Hurtownia zamawia transport w rmie przewozowej. 21

5. Firma przewozowa rezerwuje terminy, a je±li w danym okresie jest du»y popyt to postanawia zainwestowa w nowy samochód dostawczy... 6....po tygodniu okazuje si,»e mój wniosek urlopowy zostaª odrzucony z powodu niedotrzymywania terminów w aktualnym projekcie i urlop przesuwa si o 2 tygodnie, wi c staram si przesun wyjazd. Przesuni cie wyjazdu b dzie w najlepszym przypadku wi zaªo si ze strat pewnej kwoty, która zostanie potr cona jako rekompensata. Kupna nowego samochodu nie da si ju» cofn (i by mo»e nie ma potrzeby), a byª to cz ±ciowy efekt naszej decyzji, któr chcemy wycofa. U»ycie transakcji ACID w takiej sytuacji i jej odwrócenie jest niewykonalne. Okre±lenie tego scenariusza jako transakcji mo»e wi c by myl ce, dlatego w dalszej cz ±ci pracy, dla lepszego rozró»nienia, b d u»ywaª okre±le«: zadanie, proces, itp. Problemy dotychczasowych modeli Jedn z najwi kszych przeszkód dla dotychczasowych modeli jest koordynowanie ró»nych technologicznie usªug w jedn dªugotrwaª jednostk pracy, która musi zachowywa si przewidywalnie. Transakcja taka musi zachowywa integralno± biznesow danych w wielu domenach, a wymagania s cz sto okre±lane na poziomie biznesowym a nie bazodanowym. Wªa±ciwe koordynowanie transakcji i spójno±ci swoich danych biznesowych jest podstaw w poprawnym dziaªaniu przedsi biorstwa. Zªo»one aplikacje biznesowe musz wspóªdziaªa z wieloma usªugami w ró»nych moduªach i warstwach, np. autentykacja, wymiana danych, aplikacje wspomagaj ce podejmowanie decyzji (ang. EIS Executive Information System). Aplikacje mog by powi zane silnie (np. komunikacja synchroniczna) lu¹no (np. komunikacja komunikatami). Czas trwania mo»e by dªugi, wi c prawdopodobie«stwo pora»ki wzrasta. Dodatkowo w caªe zadanie mo»e by wª czony czynnik ludzki, np. przeczytanie maila przez dyrektora i potwierdzenie. Dziaªa«ludzi nie da si przewidzie : przerwy na kaw, wakacje, ±mier, itp. - wszystko mo»e zakªóci oryginalny proces. W tych powodów wymagania odno±nie dªugotrwaªych zada«zostaj zmienione w stosunku do tradycyjnych transakcji, np.: Jedna z aplikacji mo»e napotka bª d, ale caªe zadanie powinno si poprawnie zako«czy. W przypadku bª du caªego procesu, stan mo»e zosta odwrócony do jakiego± miejsca po±redniego, nie za± do samego pocz tku. Identyczno± stanu jest rozumiana w kategoriach biznesowych: po kupieniu biletu i anulowaniu lotu, odwróceniem b dzie zwolnienie miejsca w samolocie, zwrot zapªaty za lot, ale zapewne pomniejszony o kar za wycofanie si. Niektóre wyniki po±rednie musz by widoczne zanim caªe zadanie si zako«czy. Powy»sze wymagania niemal dyskwalikuj wªasno± atomowo±ci wykonywanego zadania. Praca mo»e by zatwierdzana w trakcie wykonywania zadania, a po bª dzie wynik musi zosta odwrócony tak, aby byª zgodny z reguªami biznesowymi. Z tego powodu obsªuga sytuacji bª dnych musi by bardzo dobrze zaprojektowana, gdy» gotowe mechanizmy nie istniej. Przez wiele lat nie powstaªo równie» rozwi zanie problemu izolacji przy dªugich okresach czasu. Algorytmy kontroli wspóªbie»no±ci pracuj ce przez dªugi okres zazwyczaj zaliczaj si do jednej z dwóch grup: pesymistyczne i optymistyczne. Pierwsza grupa zapewnia szeregowalno± transakcji poprzez blokowanie dzielonych zasobów. Blokady s zakªadane na caªy czas trwania transakcji, a inne transakcje oczekuj ce na ten sam zasób s zatrzymane zanim blokada nie zostanie zdj ta. Je±li transakcja trzyma blokad przed dªugi okres, to praca 22

wspóªbie»na jest niemo»liwa. Przy drugiej strategii kontroli wspóªbie»no±ci, zakªada si optymistycznie,»e dane u»ywane przez transakcje nie b d zmieniane. Przez zatwierdzeniem nast puje sprawdzenie wyniku i je±li dane okazaªy si niepoprawne (np. zmieniªy si w mi dzyczasie), to nast puje odwrócenie. Przy krótkich transakcjach taki mechanizm, okazuje si bardzo u»yteczny i cz sto pozwala na zwi kszenie wspóªbie»no±ci przy odczytach danych. Niestety prawdopodobie«stwo odwrócenia wzrasta z wydªu»aniem si»ycia transakcji. Z tych powodów wªasno±ci ACID powinny zosta osªabione. Dªugotrwaªe zadania musz zapewnia spójno± danych oraz ich trwaªo±, ale niekoniecznie atomowo± i izolacj w rozumieniu tradycyjnych transakcji. 1.2.2. Transakcje ªa«cuchowe W tych sytuacjach sprawdza si inne rozbicie transakcji. Transakcje ªa«cuchowe dekomponuj dªug transakcj na mniejsze, wykonywane sekwencyjnie. Zgodnie z [Gray93], pomysª pochodzi z produktów: IBM Information Management System (IMS) oraz bazy danych HP Allbase. Idea jest wariantem mechanizmu punktu zapisu, gdzie podtransakcja b d ca w ªa«cuchu odpowiada przedziaªom pomi dzy dwoma punktami. Istotn ró»nic jest fakt,»e podtransakcja sama w sobie jest atomowa, podczas kiedy przedziaª jest cz ±ci atomowej transakcji. W ªa«cuchu, zatwierdzana podtransakcja wyzwala nast pn, jedna po drugiej, dopóki caªa transakcja ªa«cuchowa nie zostanie zatwierdzona. Atomowo± i izolacja nie s ju» gwarantowane dla caªego ªa«cucha. W przypadku napotkania bª du, wyniki wszystkich poprzednio zatwierdzonych transakcji zostaªy ju» utrwalone, wi c jedynie wyniki aktualnie wykonywanej transakcji s anulowane. W ten sposób odwracanie transakcji mo»e jedynie przywróci system do stanu z pocz tku ostatnio wykonywanej podtransakcji, z pozostaªymi nale»y sobie radzi samemu. Dodatkowym problemem jest fakt,»e cz ±ciowe wyniki po utrwaleniu mógªy zosta wykorzystane przy wykonywaniu innych wspóªbie»nych transakcji. 1.2.3. Saga Bazuj c na idei transakcji ªa«cuchowych w pracy [Garc87] autorzy przedstawiaj sag kombinacj mechanizmu kompensacji i odwracania. Model ten staª si podstaw wielu pó¹niejszych narz dzi obsªugi zaawansowanych transakcji. Podtransakcje Tak jak w transakcjach ªa«cuchowych, pomysª polega na rozbiciu dªugotrwaªej transakcji na sekwencje mniejszych, grupuj cych powi zane operacje. Ka»da z nich zachowuje wªasno±ci ACID, natomiast sama saga nie. Podtransakcje mog by wykonywane w przeplocie podtransakcjami z innych sag (patrz rys. 1.3). Kompensacje Na poziomie ka»dej podtransakcji, po bª dzie mo»e ona zosta odwrócona w tradycyjny sposób. Jednak poprzednie transakcje w sekwencji sagi, zostaªy ju» zatwierdzone i jest za pó¹no na ich odwrócenie. W momencie kiedy drug, b d¹ kolejn podtransakcj sagi napotka bª d, saga zostanie w po±rednim stanie, w którym cz ± pracy zostaªa ju» wykonana. W tych sytuacjach u»yteczny staje si nowy mechanizm kompensacje. Programista powinien dla ka»dej operacji zaprojektowa odpowiedni kompensator, który musi wykona 23