Welcome Guest Search | Active Topics | Members | Log In

Transakcje Options · View
michal
Posted: Thursday, December 23, 2004 11:00:58 PM

Rank: Advanced Member

Joined: 12/6/2004
Posts: 332
Points: -61
w jakis sposob checmy wprowadzic transakcje do jezyka?
tradycyjnie, tzn tak? :

Code:
// start sesji = poczatek transakcji
a := 0;
try {
  a := a + 1;
  commit;
  // poczatek nowej transakcji
}
catch (e : Exception) {
  rollback;
  // poczatek nowej transakcji
}


czy jakos inaczej?

a co z:
- podtransakcjami?
- transakcjami autonomicznymi?
- kompensacjami?

zapraszam do skladania propozycji ...
subieta
Posted: Monday, December 27, 2004 6:41:58 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
michal wrote:
w jakis sposob checmy wprowadzic transakcje do jezyka?
tradycyjnie, tzn tak? :

Code:
// start sesji = poczatek transakcji
a := 0;
try {
  a := a + 1;
  commit;
  // poczatek nowej transakcji
}
catch (e : Exception) {
  rollback;
  // poczatek nowej transakcji
}


czy jakos inaczej?

a co z:
- podtransakcjami?
- transakcjami autonomicznymi?
- kompensacjami?

zapraszam do skladania propozycji ...



Po pierwsze, w ramach jednej sesji uzytkownika moze byc dowolnie duzo transakcji. Wynika stad, ze nawias rozpoczecia transakcji moze sie pojawic w dowolnym momencie, tak samo jak jeden z nawiasow zakonczenia transakcji (commint, abort). Transakcje mozna rozpatrywac z punktu widzenia kodu zrodlowego oraz run time. Najbardziej podoba mi sie pomysl, aby kod transakcji traktowac podobnie jak procedure, byc moze z parametrami. Taki pomysl zaproponowalemn studentowi p. Marcinowi Domańskiemu. Syntaktycznie procedura i transakcja wygladalaby identycznie, z wyjatkiem pierwszego slowa kluczowego:
Code:
transaction TransactionName( parameters ) {
..... abort;
......
..... commit;
.....
}


Abort oznacza instrukcje zerwania transakcji, commit oznacza instrukcje potwierdzenia transakcji. Wyjscie przez koncowy nawias jest rownowazne abort (t.j przyjmujemy defaultowo, ze programista musi wydac commit explicite) Commit musi byc wydany wewnatrz ciala tej transakcji, nie moze byc ukryty np. wewnatrz procedury wywolanej z wnetrza tej transakcji. Pozostala semantyka wywolania - jak dla procedur, lacznie z inicjacja na stosie rekordu aktywacyjnego dla parametrow i zmiennych lokalnych transakcji. Taka postac oznacza zwiekszone mozliwosci modelowania pojeciowego, gdyz transakcja posiada w ten sposob nazwe, swoja tozsamosc umozliwoajaca m.in. przechowywanie jej kodu w bazie danych i operacje na tym kodzie, np. zmiane. commit oraz abort moga takze cos zwracac, po to np. aby programiscie zasygnalizowac przyczyny powodzenia lub niepowodzenia transakcji; odpowiednie komendy moga byc
Code:
commit and return <query>;
Code:
abort and return <query>;

Rozwiazanie to pochodzi z systemu DBPL, ktory wraz z Florianem Matthesem, Joachimem Schmidtem i Andreasem Rudlofem zaimplementowlismy w latach 1991-93.

Wykonanie transakcji oznacza, ze konkretna transakcja jest wolana tak jak procedura. Runtimowa transakcja otrzymuje swoj handle, ktorego skladnikiem jest identyfikator sesji uzytkownika. Jest rzecza dyskusyjna czy jak w ODMG taki handle ma byc identyfikowalny w programie (jak w ODMG), tak aby ktos z zewnatrz transakcji posluzyl sie nim np. do zerwania transakcji. Jezeli taki handle ma byc, to powinien on miec postac obiektu z atrybutami takimi jak: id_transakcji, id_sesji, login_uzytkownika, czas rozpoczecia, ilosc zmodyfikowanych danych, itp. To pozwoli administratorowi o odpowiednich uprawnieniach zarzadzac transakcjami np. zrywac je w sytuacji zakleszczenia lub koniecznosci zwolnienia zasobow.

Koncepcja w naturalny sposob pozwala na zagniezdzanie transakcji. Zagniezdzanie nic nie implikuje oprocz tego, ze wykrywana jest ilosc otwartych transakcji na stosie i jezeli otwarta transakcja ma pod spodem inna otwarta transakcje, to abort tej zagniezdzonej oznacza wycofanie i zwolnienie zablokowanych zasobow (z przekazaniem informacji do nad-transakcji), zas commit oznacza odpowiednia informacje dla naddtransakcji i przekazanie do niej wszystkich blokad. Blokady (fizyczne zamki na dysku), moga byc rowniez pamietane na stosie, co usprawni proces ich przekazywania do nadtransakcji.

Poniewaz docelowo ODRA ma byc systemem rozproszonym (gridowym) konieczne jest jeszcze rozpatrzenie kwestii wystawiania sygnalow gotowosci. Skladniowo transakcja moze wygladac tak samo, ale jest wywolana w innym trybie, ktory powoduje, ze w momencie commit transakcja nie konczy swojej dzialalnosci, ale wystawia sygnal gotowosci, ktory programista moze badac. Nie wiem jak to najzgrabniej zrobic skladniowo, poniewaz w tym przypadku zaraz po wywolaniu transakcji programista powinien miec handle, poprzez ktore moze te transakcje odpytac na okolicznosc jej stanu oraz ewentualnie zerwac lub potwierdzic. Nie wiem tez jak zrobic timeouty, czyli jak dlugo taka transakcja ma czekac na commit ze strony zewnetrznej. To sa pewne drobne problemy, ktore nalezy ulozyc w przyjemny i logiczny syntax.

Nie wiem co Michal rozumie pod pojeciem transakcje autonomiczne - czy chodzi o te wykonywane na lokalnych serwerach? Jezeli lokalne serwery nie udostepniaja zadnych informacji o transakcjach, ktore sa na nich wykonywane, i nie umieja wystawiac sygnalow gotowosci, to w zasadzie nic sie nie da zrobic. Byly jakies tam pomysly, niestety, jak sie wydaje wszystkie je mozna potluc o kant. Przyjmimy wiec, ze wrappery definiowane na lokalnych serwerach beda tak napisane, aby dostosowac sie do naszej konwencji i naszych interfejsow w zakresie przetwarzania rozproszonych transakcji. Jezeli dla jakiego serwera to sie nie uda, to moim zdaniem nic sie nie da zrobic bez naruszania jego autonomii (czyli zmiany oprogramowania, ktore na nim chodzi).

Jezeli chodzi o kompensacje, to wprawdzie objasniam ten pomysl na wykladzie, ale w gruncie rzeczy jestem przekonany ze Hektor i spolka wywazaja tu otwarte drzwi robiac z tego jakies chytre "sagi". Kompensujaca podtransakcja jest zwyczajna podtransakcja i kazdy moze ja sobie napisac, czyli calosc juz sie miesci w tym, co opisalem. Warunkiem jest to, ze programista bedzie wiedzial jak potoczyla sie ta glowna podtransakcja, a to moze wiedziec na podstawie wspomnianego handle lub tego co zakonczona podtransakcja zwroci na swoim grzbiecie.
KK
Posted: Tuesday, December 28, 2004 4:19:22 PM
Rank: Advanced Member

Joined: 12/7/2004
Posts: 226
Points: 30
Świetnie, że Michał rozpoczął ten wątek, bo już dawno chciałem spytać o rozproszone transakcje w naszym Gridzie.

Z tego co zrozumiałem, to jest tak, że w procedurze w Global View wywoływane są odpowiednio transakcje na poszczególnych węzłach i jeżeli każda z nich potwierdzi, że jest sukces i jest gotowa do zakończenia, to całościowa transakcja jest potwierdzana.

Rozumiem, że transakcje blokują też potrzebne zasoby na niezbędny czas. Czyli, że transakcja wywołana na GV zablokuje aż do czasu potwierdzenia lub zerwania, potrzebne zasoby na poszczególnych węzłach. I jeśli będzie więcej tych Global View to będą się nawzajem blokować, aż któryś zakończy pierwszy.
A jaki model usuwania zakleszczeń?
michal
Posted: Wednesday, December 29, 2004 7:31:57 PM

Rank: Advanced Member

Joined: 12/6/2004
Posts: 332
Points: -61
pomysl z transakcjami jako procedurami bardzo mi sie podoba.
zakladam natomiast ze razem z sesja uruchamiana jest transakcja glowna,
a dopiero kazde kolejne wywolanie procedury z atrybutem transaction
odpala podtransakcje? czy tez moze kod wykonywany poza
procedura transakcji nie jest objety mechanizmem transakcji?

transakcje autonomiczne sa podobne do podtransakcji,
ale ich wykonanie jest niezalezne od nadtransakcji. jest to po prostu
nowa, niezalezna transakcja. przydaje sie np. do logowania
dostepu niezaleznie od tego, czy transakcja nadrzedna
zakonczyla sie pomyslnie czy nie. w naszym przypadku
taka transakcja moze byc deklarowana z dodatkowym slowkiem autonomous,
wiec nie powinno byc problemu z jej dorobieniem.

w bazach relacyjnych informacje o biezacych transakcjach umieszczane
sa w katalogu, gdzie istnieja specjalne "perspektywy",
ktorych zadaniem nie jest jednak prezentowanie zawartosci bazy danych,
ale wewnetrznych struktur szbd. byc moze cos takiego
mozemy rowniez zrobic ?

transakcje w srodowisku gridowym proponuje na razie sobie
darowac. to co mnie natomiast bardziej interesuje to temat pokrewny
z transakcjami, mianowicie watki. czy watki rowniez mozemy
zrobic skladniowo w sposob podobny do transakcji? tzn. wywolanie
procedury z atrybutem thread odpala watek, a jej zakonczenie,
zatrzymuje go? czy tez powinnismy zrobic jakas specjalna
klase Thread, tak jak w javie?

czescia wspolna problemu watkow i transakcji jest blokowanie.
blokady raczej bazodanowe (automatyczne) niz
jezykowe (zakladane recznie sekcje krytyczne)? trzeba zatem podjac jakas
decyzje w dziedzinie poziomow izolacji transakcji.
np. czy moze byc read uncommited?
KK
Posted: Tuesday, January 11, 2005 5:04:46 PM
Rank: Advanced Member

Joined: 12/7/2004
Posts: 226
Points: 30
Z transakcjami i wirtualnymi obiektami w Gridzie mam jeszcze jeden problem.

Może się zdażyć, że taka transakcja będzie dość długo trwała. Czy obiekty źródłowe blokujemy aż do zakończenia transakcji? Jeśli chcemy by obiekty wirtualne miały zawsze aktualny stan bazy, a rozumiem, że tak być musi, to liczba potrzebnych blokad może być bardzo duża. Czy w rozproszonym systemie z danymi w bardzo wielu miejscach i naszym stosem, który nieustannie obraca bardzo dużą ilością binderów nie doprowadzi to do totalnego zakleszczenia?
michal
Posted: Tuesday, January 11, 2005 6:53:53 PM

Rank: Advanced Member

Joined: 12/6/2004
Posts: 332
Points: -61
pamietaj ze w bazach danych sa rozne rodzaje blokad -
blokada x nie jest jedyna. jest jeszcze r i rozne kombinacje r i x.
poza tym sa pewne mechanizmy zwiazane z nieblokujacym
odczytem, poziomami izolacji transakcji itd.
stencel
Posted: Tuesday, January 11, 2005 8:38:41 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
michal wrote:
np. czy moze byc read uncommited?


To jest poziom nie-izolacji. Czy miales na mysli READ COMMITED?
subieta
Posted: Thursday, January 13, 2005 7:27:35 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
stencel wrote:
michal wrote:
np. czy moze byc read uncommited?


To jest poziom nie-izolacji. Czy miales na mysli READ COMMITED?


SQL w wydaniu SQL-92 ma takie cos jak poziomy izolacji, ktore spotkaly sie z dosc ozywiona dyskusja i protestem wielkich bazodanowych guru (zapomnialem jaki to byl artykul). Natomiast dla wszystkich jest w zasadzie jasne, ze musi byc jakis sposob na "brudny odczyt", bo inaczej pewne procesy nigdy nie dojda do celu. Np. bank ma na koniec dnia w ciagu 15-tu minut sporzadzic zestawienie wszystkich aktualizowanych kont dla celow monitorowania bezpieczenstwa i z punktu widzenia tego raportu nie jest istotne czekanie na koniec aktualizacji pewnego konta (bo uzytkownik aktualnie cos dlugo marudzi przy bankomacie). Jezeli taki bank ma 10 000 bankomatow, zas proces bedzie zatrzymywal sie na kazdym w tej chwili aktualizowanym koncie, to sporzadzenie tego raportu bedzi trwalo powiedzmy 3 dni (szczegolow nie pamietam, ale taki benchmark byl robiony przez pewnien bank w Los Angeles). To wlasnie byl argument zwolennikow oslabiania posiomow izolacji. Z drugiej strony, jezeli takie "brudne odczyty" damy do raczek "brudnym programistom" to moga oni niezle narozrabiac. No i trudno, nic w zyciu nie jest doskonale, skoro tego nie mozna zrobic inaczej, to nalezy dac tym malpom do reki taka brzytwe, a jezeli sie pochlastaja, to sami sobie winni i jeszcze nalezy ich przykladnie ukarac. Pytanie tylko takie jak te brzytwe maksymalnie stepic aby robila co trzeba a ryzyko pochlastania sie bylo minimalne. Mozna np. poprzez poziomy ufnosci do programisty, ktore sa nadawane przez administratora w okreslonym celu i odbierane natychmiast po zrealizowaniu celu.
subieta
Posted: Friday, May 16, 2008 10:49:56 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Wracam do wątku transakcji. Uważam, że poziomów izolacji nie powinno być (bo to nieeleganckie), natomiast programista może odpytać, która transakcja blokuje jego transakcję i ją zerwać. To wymaga albo odpowiednich uprawnień ze strony administratora, albo też przypisanie traksakcjom priorytetów: transakcja o wyższym priorytecie może zerwać transdskcję o niższym priorytecie.

Tranakcje jako obiekty runtime-owe mają swój stan i mogą być odpytywane na normalnych zasadach poprzez SBQL. Należą one do specjalnej klasy, która zawiera wszystkie operacje niezbędne programiście do zarządzania transakcjami, w tym obcymi transakcjami. Programista ma możliwość odpytania w programie przed próbą dostępu do pewnych obiektów, czy nie są one blokowane przez obce transakcje oraz przez które. Może odczytać stan tych transakcji, taki jak stemple czasowe, priorytet, ilość wykonanej pracy, założone blokady, stan gotowości, itd. Może też wykonać operację "zerwij obcą transakcję". Ta operacja będzie różniła nasze rozwiązanie od isolation levels w SQL.

Można rozważyć wersje optymistyczne algorytmu przetwarzania transakcji, polegające na zakładaniu stempli czasowych i ich sprawdzaniu w momencie zapisu zmienianego rekordu do bazy danych. Jezeli stempel się nie zgadza, to nalezy zerwac daną transakcję. Jezeli stempel zawieralby identyfikatory innych transakcji, które nadpisaly nasz stempel, to można je zerwac zamiast naszej, przy spelnieniu odpowiednich warunków (wszystkie transakcje sa w toku, zadna nie zrobila commit, ich priorytet lub koszt jest niższy od naszej, itd.) Zakladanie i sprawdzanie stepmli nie może być równoległe - powinna to być funkcja monitora transakcji, który obsluguje zlecenia zakladania i zwalniania stempli w trybie synchronicznym. Inaczej metoda stempli wymagalabym jednak jakiejs formy blokady.

Granularność transakcji: raczej fizyczny blok niż obiekt. Jezeli jednak zdecydujemy sie na blokowanie lub stpmplowanie obiektów, to ich granularność nie może być zbyt mała. Można również rozważać blokowanie na poziomie meta-modelu, czyli np. zablokować atrybuty danej klasy o określonej nazwie. Jezeli na to się decydujemy, to wszystkie pozostałe operacje (aktualizacja indeksu, zbieranie smieci, itd) nie mogą byc asynchroniczne - problem podobny do zakładania/zdejmowania stempli.

Zapraszam do dyskusji nad konkretnymi rozwiązaniami.
Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Main Forum RSS : RSS

Powered by Yet Another Forum.net version 1.9.1.6 (NET v2.0) - 11/14/2007
Copyright © 2003-2006 Yet Another Forum.net. All rights reserved.
This page was generated in 0.177 seconds.