Rozdział I Zastosowanie mechanizmów długich transakcji w systemie ewidencji gruntów i budynków Streszczenie. Transakcje s mechanizmem dostpnym w systemach zarzdzania bazami, którego podstawowym zadaniem jest utrzymanie spójnoci w czasie ich zmiany oraz koordynacja współbienoci dokonywania zmian. Wyróni mona krótkie transakcje zaimplementowane w wikszoci systemów zarzdzania bazami oraz długie transakcje, obsług których niejednokrotnie trzeba oprogramowa w aplikacji systemu informacyjnego W rozdziale przedstawiono ide mechanizmów długich transakcji w dwóch systemach ewidencji gruntów i budynków. W pierwszym systemie długie transakcje zaimplementowano w jednym schemacie bazy, a w drugim systemie - w trzech schematach biecym, transakcyjnym i archiwalnym. Obie implementacje oparte s na metodzie wersjonowania obiektów. 1 Wprowadzenie Transakcje s mechanizmem dostpnym w systemach zarzdzania bazami, którego podstawowym zadaniem jest utrzymanie spójnoci w czasie edycji oraz koordynacja współbienoci dokonywania zmian w. Transakcje obejmuj cig operacji aktualizacyjnych, przekształcajcych baz systemu informacyjnego z jednego stanu spójnego w inny spójny stan. Ten cig operacji aktualizacyjnych traktuje si jako atomowy, niepodzielny. Klasyczne transakcje mona nazwa krótkimi transakcjami, bowiem musz one si zakoczy w momencie zakoczenia pracy aplikacji systemu informacyjnego albo systemu zarzdzania bazami. Krótkie transakcje nazywane s równie bazodanowymi, bowiem s one standardowym mechanizmem wikszoci systemów zarzdzania bazami. Jednake, w niektórych systemach, np. systemach klasy CAD lub w systemach ewidencji gruntów i budynków, ze wzgldu na złoony proces aktualizacji, konieczne s funkcje odkładania transakcji w toku oraz wznawiania niedokoczonych transakcji po upływie dowolnego czasu. Funkcje takie realizuje si za pomoc tzw. długich transakcji, które naley oprogramowa w aplikacji systemu. Dlatego te długie transakcje mona nazwa transakcjami aplikacyjnymi. Niemniej jednak długie transakcje musz spełnia cztery podstawowe własnoci transakcji ACID. ACID jest akronimem angielskich nazw podstawowych własnoci transakcji: atomowo (ang. atomicity), spójno (ang. consistency), wyłczno (ang. isolation) oraz trwało (ang. durability). Długie transakcje s przedmiotem licznych publikacji i proponowane s róne mechanizmy i procedury zarzdzania nimi [1], [2], [3], [4], [7], [8], [9]. Bogdan Trawiski: Politechnika Wrocławska, Instytut Informatyki Stosowanej, Wybrzee Wyspiaskiego 27, 50-370 Wrocław, Polska trawinski@pwr.wroc.pl
B. Trawiski W niniejszym rozdziale przedstawiono ide mechanizmów długich transakcji w dwóch systemach ewidencji gruntów, budynków i lokali. W pierwszym systemie długie transakcje zaimplementowano w jednym schemacie bazy, a w drugim systemie - w trzech schematach biecych, transakcyjnych i archiwalnych. Obie implementacje oparte s na metodzie wersjonowania obiektów [6], [11]. 2 Własnoci krótkich transakcji Zarówno krótkie, bazodanowe transakcje, jak i długie, aplikacyjne transakcje systemu musz spełnia cztery podstawowe własnoci transakcji ACID. Własnoci te mona scharakteryzowa w sposób nastpujcy: Atomowo oznacza, e operacje aktualizacyjne objte transakcj naley traktowa, jako niepodzieln cało. Stawia to wymóg, by wszystkie operacje czstkowe zakoczyły si powodzeniem. Jeeli którakolwiek z operacji czstkowych nie wykona si, to wszystkie operacje aktualizacyjne wykonane w ramach transakcji to tego momentu musz zosta wycofane, a baza musi powróci do stanu sprzed rozpoczcia transakcji. Spójno oznacza, e stan bazy jest spójny zarówno przed transakcj, jak i po transakcji. Jeeli system nie moe osign spójnego stanu bazy w czasie transakcji, to musi wycofa transakcj i przywróci stan bazy sprzed transakcji. Wyłczno oznacza, e system musi mie czasie wykonywania transakcji wszystkie niezbdne zasoby na wyłczno. Osiga to poprzez zastosowanie mechanizmu blokowania (ang. locking) rekordów, stron, tabel albo nawet całej bazy. Trwało oznacza, e rezultaty transakcji po jej zatwierdzeniu s stabilne. Po zatwierdzeniu transakcji nie ma ju moliwoci powrotu do stanu sprzed transakcji. Wykonaniem transakcji steruj trzy podstawowe operacje, którym odpowiadaj instrukcje w jzykach programowania: rozpoczcie, otwarcie transakcji (ang. begin transaction), zatwierdzenie transakcji (ang. commit transaction), wycofanie transakcji (ang. rollback transaction). Po rozpoczciu transakcji kada kolejna instrukcja selekcji, aktualizacji, wstawienia i usunicia objta jest regułami biecej transakcji. Zatwierdzenie transakcji powoduje utrwalenie wyników działania wszystkich instrukcji objtych transakcj i utrat moliwoci powrotu do stanu sprzed transakcji. Z kolei wycofanie transakcji powoduje anulowanie wyników wszystkich instrukcji wykonanych w transakcji, czyli odzyskanie spójnego stanu, jaki baza miała przed transakcj. Wycofanie transakcji moe by oprogramowane w aplikacji systemu informacyjnego. Natomiast w wypadku wystpienia awarii sprztu lub oprogramowania system zarzdzania baz sam automatycznie wycofuje transakcj. Z blokowaniem zasobów wie si zagadnienie poziomów izolacji transakcji, które dotyczy zakresu, w jakim zmiany wykonane przez dan transakcj s widoczne dla innej transakcji. Poziomy izolacji transakcji definiuje si je wystpowaniem, wzgldnie niewystpowaniem niepo zjawisk: brudnego odczytu, niepowtarzalnego odczytu, fantomu. Te niepodane zjawiska opisane s w [6], [12], [13]. Wyrónia si cztery poziomy izolacji transakcji: Niepotwierdzony odczyt (ang. read uncommitted) transakcja działajca na poziomie odczytu niepotwierdzonego widzi niepotwierdzone zmiany dokonywane przez inne transakcje. Na tym poziomie moliwe jest wystpienie brudnego odczytu, niepowtarzalnego odczytu oraz fantomu. 2
Zastosowanie mechanizmów długich transakcji w systemie ewidencji gruntów i budynków Potwierdzony odczyt (ang. read committed) transakcja działajca na poziomie odczytu potwierdzonego nie widzi zmian dokonywanych przez inne transakcje dopóki nie zostan one potwierdzone przez te transakcje. Na tym poziomie nie jest moliwy brudny odczyt, natomiast moliwe jest wystpienie niepowtarzalnego odczytu oraz fantomu. Powtarzalny odczyt (ang. repeatable read) - transakcja działajca na poziomie powtarzalnego odczytu ma gwarancj, e nie bdzie widzie adnych zmian dokonanych przez inne transakcje na, które ju raz odczytała. Na tym poziomie nie jest moliwy brudny odczyt i niepowtarzalny odczyt, natomiast moliwe jest wystpienie fantomu. Poziom szeregowalny (ang. serializable) transakcje działajce na poziomie szeregowalnym tak współdziałaj ze sob, jak gdyby kada transakcja była wykonywana jedna po drugiej. Transakcje s od siebie odizolowane. Na tym poziomie nie jest moliwe zjawisko ani brudnego odczytu, ani niepowtarzalnego odczytu, ani fantomu. W rozdziale zostan przedstawione dwa warianty realizacji długich transakcji w systemie informacyjnym. Pierwszy realizowany jest za pomoc trzech schematów bazy : biecego, transakcyjnego oraz archiwalnego, a drugi za pomoc statusów obiektów w jednym schemacie bazy. Ponadto przeprowadzone zostan rozwaania, jak spełni własnoci ACID w obu wariantach oraz jak osign poziomy izolacji transakcji: niepotwierdzony odczyt i potwierdzony odczyt. 3 System ewidencji gruntów i budynków Opis procesu długich transakcji przedstawiono w niniejszym rozdziale na przykładzie systemów informacyjnych przeznaczonych do prowadzenia ewidencji gruntów i budynków, w pracach nad opracowaniem i rozwojem których autor uczestniczy. Systemy tej klasy utrzymuj dane opisowe i geometryczne dotyczce wszystkich nieruchomoci z całego terytorium kraju. Eksploatowane s one w kadym starostwie powiatowym. Ich funkcjonowanie jest obwarowane przepisami prawnymi [10] oraz instrukcj techniczn G5. Przepisy te stawiaj wymóg stosowania w nich długich transakcji. Rys. 1. Diagram powiza relacyjnych pomidzy obiektami w jednostce rejestrowej 3
B. Trawiski W tych systemach dane o włacicielach nieruchomoci grupowane s w tzw. jednostkach rejestrowych, które obejmuj nieruchomoci w danym obrbie ewidencyjnym jednorodne pod wzgldem prawnym, np. zarejestrowane w jednej ksidze wieczystej. powiza relacyjnych pomidzy podstawowymi obiektami ewidencyjnymi w jednostce rejestrowej gruntów przedstawiono na rys. 1. Obiektami tymi s działka ewidencyjna (tabela Dzialki), klasouytki na działce (tabela Klasouzytki), udziały włacicieli i władajcych (tabela Udzialy) oraz podmioty ewidencyjne (tabela PodmiotyEwid). Jedna jednostka rejestrowa moe obejmowa wiele działek ewidencyjnych oraz wiele udziałów podmiotów ewidencyjnych. Przy czym suma udziałów włacicieli oraz suma udziałów władajcych jednostce rejestrowej musz by równe 1. Wszystkie te obiekty umiejscowione s w ramach obrbów ewidencyjnych (tabela Obrby), na które podzielone s jednostki ewidencyjne (tabela Gminy). 4 Długie transakcje w jednym schemacie bazy Do koordynacji zmian dokonywanych w jednostce rejestrowej w czasie długiej transakcji wykorzystywane s pola Status wystpujce w kadej tabeli obiektów. W czasie trwania długiej transakcji obiekty działek, klasouytków na działce, udziałów oraz podmiotów ewidencyjnych mog przyjmowa nastpujce statusy: 4 0 obiekt biecy, niepodlegajcy w danym momencie zmianie, 1 obiekt archiwalny, obiekt zmieniony w przeszłoci, przed rozpoczciem rozpatrywanej transakcji, 2 obiekt dopisany obiekt dopisany w rozpatrywanej transakcji, 3 obiekt zmieniony obiekt zmieniony w rozpatrywanej transakcji, obiekt z danymi sprzed aktualizacji, przeznaczony do przeniesienia do archiwum. Z kolei jednostka rejestrowa, poza statusami 0 bieca, niebdca w trybie zmian oraz 1 archiwalna, moe przyjmowa dwa dodatkowe statusy: 8 długa transakcja jest aktualnie wykonywana, 9 długa transakcja została odłoona do wznowienia i kontynuacji w przyszłoci. Rozpoczcie długiej transakcji polega na zablokowaniu jednostki rejestrowej do zmian poprzez ustawienie w polu Status wartoci 8. Przed rozpoczciem długiej transakcji wszystkie obiekty w jednostce rejestrowej s albo biece albo historyczne, czyli maj statusy równe 0 albo 1. Obiekty historyczne nie podlegaj zmianom, a zatem nie bior udziału w transakcji. Jeeli którykolwiek z obiektów o statusie biecym: działka, klasouytek na działce, udział lub podmiot ewidencyjny ulega zmianie, to rekord tego obiektu jest powielany. Rekord z danymi obiektu sprzed aktualizacji uzyskuje status wynoszcy 3, a rekord z danymi obiektu po aktualizacji otrzymuje status równy 2. Długa transakcja moe zosta odłoona do dokoczenia po upływie dowolnego czasu. W czasie odkładania transakcji status jednostki rejestrowej ustawiany jest na 9, a statusy pozostałych obiektów pozostaj bez zmian. Wznowienie transakcji odłoonej odbywa si poprzez zmian poprzez przywrócenie jednostce rejestrowej statusu 8, który oznacza, e transakcja jest wykonywana. W czasie zatwierdzenia transakcji obiekty dopisane staj si biecymi, a obiekty zmienione archiwalnymi, czyli zmieniane s statusy obiektów z 2 na 0 oraz z 3 na 1.
Zastosowanie mechanizmów długich transakcji w systemie ewidencji gruntów i budynków Status jednostki rejestrowej zmieniany jest z 8 na 0. Z kolei w wypadku koniecznoci wycofania transakcji obiekty ze statusem 3 s przywracane jako biece, a wic uzyskuj status 0, natomiast obiekty dodane posiadajce status 2 s fizycznie usuwane z bazy. Status jednostki rejestrowej zmieniany jest z 8 na 0. Jednostka rejestrowa powraca wic do stanu sprzed transakcji. Diagram zmiany stanów obiektów takich, jak działka, klasouytek na działce, udział lub podmiot ewidencyjny przedstawiono na rys. 2. Rys. 2. Diagram stanów obiektu w czasie długiej transakcji w notacji UML Jeeli w czasie wykonywania transakcji inny uytkownik chce uruchomi swoj transakcj na tej samej jednostce rejestrowej, to aplikacja sprawdza stan zablokowania jednostki i uniemoliwia otwarcie innej transakcji. Zatem w tym wypadku, poziom izolacji transakcji jest szeregowalny. Z kolei, jeeli inni uytkownicy wykonuj raporty lub zestawienia statystyczne, obejmujce dane z jednostki rejestrowej, w której uruchomiona jest długa transakcja, udostpniane s dane sprzed rozpoczcia transakcji. A wic raporty uwzgldniaj dane obiektów ze statusem 0 i 3, bo takie obiekty były biece przed transakcj, natomiast pomijane s dane obiektów ze statusem 1 i 2, bo dotycz one obiektów archiwalnych albo dopisanych w czasie niezatwierdzonej jeszcze transakcji. A zatem dane do raportów udostpniane s na poziomie izolacji transakcji potwierdzonego odczytu. Gdyby potrzebny był poziom niepotwierdzonego odczytu, to naleałoby udostpni dane obiektów ze statusem 0 i 2. Przedstawiony powyej sposób przetwarzania długich transakcji zapewnia wic zachowanie własnoci ACID oraz działanie na szeregowalnym poziomie izolacji transakcji. Ponadto kada zmiana obiektów, jak i zmiany statusów jednostki rejestrowej oraz pozostałych obiektów zapisywane s trwale w bazie przy uyciu krótkich transakcji. 5
B. Trawiski 5 Długie transakcje w trzech schematach bazy Do wykonywania długich transakcji wykorzystywane s trzy odrbne schematy bazy : schemat biecych - słuy do udostpniania biecych, które jest najczciej wykorzystywan funkcj w systemie, schemat transakcyjnych - słuy do wykonywania aktualizacji, zawiera wic tylko dane poddawane w danym momencie zmianom, schemat archiwalnych zawiera zarówno dane biece, jak i archiwalne, słuy do udostpniania historycznych, czyli takich, które były aktualne w danym momencie w przeszłoci. Do koordynacji zmian dokonywanych w jednostce rejestrowej w czasie długiej transakcji, co ma miejsce w schemacie transakcyjnym, podobnie do długich transakcji w jednym schemacie bazy, wykorzystywane s pola statusów obiektów. 5.1 Faza otwierania długiej transakcji Faza otwierania długiej transakcji polega na zablokowaniu do zmiany jednostki rejestrowej, poprzez ustawienie jej statusu na 8 w schemacie biecych, a nastpnie na skopiowaniu wszystkich tej jednostki rejestrowej do schematu transakcyjnego (Rys. 3). Ustawianie statusu zablokowania jednostki rejestrowej i kopiowanie odbywa si przy uyciu krótkich transakcji. 1. Załoenie blokad biecych 2. Kopiowanie transakcyjnych archiwalnych Rys. 3. Operacje w czasie fazy otwierania długiej transakcji 5.2 Faza wykonywania długiej transakcji Aktualizacja odbywa si w schemacie transakcyjnym. Jej przebieg jest analogiczny do procesów zmian wykonywanych w ramach długiej transakcji w jednym schemacie bazy, opisanych w poprzednim punkcie niniejszego rozdziału (Rys. 4), do koordynacji zmian dokonywanych w jednostce rejestrowej równie wykorzystywane s statusy obiektów. Wszystkie raporty i zestawienia statystyczne wykonywane s w schemacie biecych, a wic udostpniane s w postaci sprzed rozpoczcia transakcji, czyli wyłcznie na poziomie izolacji transakcji potwierdzonego odczytu. Odłoenie długiej transakcji do póniejszego wznowienia i dokoczenia polega tylko na zmianie statusu jednostki rejestrowej z 8 na 9 zarówno w schemacie transakcyjnym, jak i biecym. Analogicznie, wznowienie odłoonej transakcji polega na zmianie statusu jednostki rejestrowej z 9 na 8. 6
Zastosowanie mechanizmów długich transakcji w systemie ewidencji gruntów i budynków Aktualizacja biecych transakcyjnych archiwalnych Rys. 4. Operacje w czasie fazy wykonywania długiej transakcji 5.3 Faza zatwierdzenia długiej transakcji W czasie zatwierdzania transakcji, zaktualizowane dane kopiowane s ze schematu transakcyjnych do schematów biecych i archiwalnych, a nastpnie zwalniana jest blokada jednostki rejestrowej, poprzez zmian jej statusu z 8 na 0. Zarówno kopiowanie zaktualizowanych, jak i odblokowywanie jednostki rejestrowej odbywa si przy uyciu krótkich transakcji. Jeeli zachodzi konieczno wycofania transakcji, to aktualizowane dane usuwane s ze schematu transakcyjnego, a nastpnie status jednostki rejestrowej przestawiany jest z 8 na 0. 3. Zwolnienie blokad biecych 1. Kopiowanie transakcyjnych 2. Kopiowanie archiwalnych Rys. 5. Operacje w czasie fazy zatwierdzania długiej transakcji Przedstawiony powyej sposób przetwarzania długich transakcji zapewnia równie zachowanie własnoci ACID oraz działanie na szeregowalnym poziomie izolacji transakcji. 6 Podsumowanie W rozdziale przedstawiono dwa warianty realizacji długich transakcji w systemie informacyjnym. Pierwszy realizowany jest za pomoc statusów obiektów w jednym schemacie bazy, a drugi za pomoc trzech schematów bazy : biecego, transakcyjnego oraz archiwalnego. W obu wariantach zachowane s własnoci ACID transakcji i w obu transakcje działaj na szeregowalnym poziomie izolacji. Warianty te zaimplementowano w dwóch systemach ewidencji gruntów i budynków. 7
B. Trawiski Literatura 1. Butler M., Ferreira C.. An operational semantics for StAC, a language for modelling longrunning business transactions. In Coordination 2004 (COORD 2004), volume 2949 of LNCS. Springer-Verlag, 2004. 2. Butler M., Ferreira C., Ng M. Y:. Precise Modelling of Compensating Business Transactions and its Application to BPEL. Technical Report, Electronics and Computer Science, University of Southampton 2004 3. Butler M., Hoare T., Ferreira C.: A trace semantics for long-running transactions. In 25 Years of CSP, 2004. 4. Chessell M., Griffin C., Vines D., Butler M., Ferreira C., Henderson P.: Extending the concept of transaction compensation. IBM Systems Journal, vol. 41, no. 4, 2002 5. Coulouris G., Dollimore J., Kindberg T.: Systemy rozproszone. Podstawy i projektowanie. WNT, Warszawa 1998 6. Koszlajda T.: Zarzdzanie współbienoci transakcji. VI Konferencja PLOUG 2000, 24-28 padziernika, Zakopane, http://www.ploug.org.pl/ 7. Lynch N.A.: Multilevel Atomicity - A New Correctness Criterion for Database Concurrency Control. ACM Transactions on Database Systems, Vol. 8, No. 4, December 1983, Pages 484-502 8. Mukherjee S.: A Modified Kangaroo Model for Long Lived Transactions Over Mobile Networks, Proceedings of the WSEAS Int. Conf. on E-Activities, Singapore, December 2002. 9. Pu C., Kaiser G.E., Hutchinson N.: Split Transactions for Open-Ended Activities, Proceedings of the 14th VLDB Conference, Los Angeles, California 1988 10. Rozporzdzenie Ministra Rozwoju Regionalnego i Budownictwa z dnia 29.03.2001r. w sprawie ewidencji gruntów i budynków (Dz.U. nr 38, poz. 454) 11. Sperat S.: Addressing high concurrency and long transactions in GIS environments. A white paper, 4DataLink February 2003, http://www.4datalink.com 12. Stokłosa J., Bilski T., Pankowski T.: Bezpieczestwo w systemach informatycznych. PWN, Warszawa-Pozna 2001 13. Ullman J.D., Widom J.: Podstawowy wykład z systemów baz. WNT, Warszawa 2000 Paper title: Implementation of long transaction mechanisms in the system for registration of parcels and buildings Abstract. Transactions are the mechanism available in data base management systems. Their fundamental task is to maintain data consistency during updating and to coordinate the concurrency of changing data. There are short transactions implemented in majority of data base management systems. You can also figure long transactions, which should be programmed in the application of an information system. The concept of the mechanisms of long transactions implemented in two systems for registration of parcels and buildings is presented in the chapter. In one system long transactions are implemented in one data base schema and in the second system they are maintained in three data base schemas. Both solutions are based on the method of object versioning. Słowa kluczowe: bazy, systemy informacyjne, długie transakcje, wersjonowanie obiektów, poziomy izolacji transakcji 8