ODE Triggery. Wstęp n Triggery są trójką zdarzenie-warunek-akcja (event-condition- action). n Zdarzenia mogą być proste lub złożone, co zostanie omówione.

Prezentacja na temat: "ODE Triggery. Wstęp n Triggery są trójką zdarzenie-warunek-akcja (event-condition- action). n Zdarzenia mogą być proste lub złożone, co zostanie omówione."— Zapis prezentacji:

1 ODE Triggery

2 Wstęp n Triggery są trójką zdarzenie-warunek-akcja (event-condition- action). n Zdarzenia mogą być proste lub złożone, co zostanie omówione w następnych punktach. n Triggery muszą być jawnie aktywizowane dla każdego obiektu. n Tylko aktywny trigger może zostać wyzwolony. n Definicja triggera występuje w klasie i jest następująca: trigger nazwa_triggera(parametry) : [perpetual] [^] zdarzenie ==> [end | [!] dependent] action

3 n Mamy trzy rodzaje zdarzeń prostych: u zdarzenia oparte na metodach klas u zdarzenia transakcyjne u zdarzenia definiowane przez użytkownika Zdarzenia proste

4 Zdarzenia oparte na metodach klas n Wywołania publicznych metod trwałych obiektów powoduja jednocześnie zajście zdarzeń w ramach tych obiektów. Np. wywołanie: p-f(...) gdzie p jest trwałym wskaźnikiem na trwały obiekt a f metodą tego obiektu powoduje zajście zdarzenia before f - które zaszło dla obiektu wskazywanego przez p przed wywołaniem metody f i zdarzenia after f - które zaszło po zakończeniu działania funkcji f. n Jeżeli f jest funkcją przeciążoną np. void f(int); int f(float); float f(); wtedy przy zdarzeniach prostych muszą być użyte ich prototypy aby rozróżnić poszczególne wywołania: before f(int); before f(float); before f();

5 Zdarzenia oparte na metodach klas (cd.) n Bezpośredni dostęp do obiektu (np. czytanie lub przypisywanie wartości publicznym atrybutom klasy) nie generuje zdarzeń. n Zagnieżdżone wywołania funkcji trwałych obiektów w jego metodach poprzez użycie zmiennej this jawnie lub niejawnie nie powoduje zdarzeń. Jedynie specjalna zmienna pthis użyta w zagnieżdżonych wywołaniach powoduje wygenerowanie zdarzeń.

6 Zdarzenia transakcyjne n Transakcja odczytująca nie może zawierać instrukcji typu update. Ponadto program zawierający jakąkolwiek taką transakcję musi zostać skompilowany z opcją -D i stałą ODE_READONLY Transakcje tego typu rzadziej powodują deadlock, zakładają bowiem tylko blokady do odczytu, oraz nie zapisują informacji w plikach typu log. Transakcje hipotetyczne powalają użytkownikom generować scenariusze typu co by było gdyby. Użytkownik może zmieniać dane i obserwować działanie (należy pamiętać o aktywności systemu) tych zmian bez rzeczywistych zmian w bazie danych. Zmiany są widziane tylko wewnątrz transakcji i nie są widziane przez innych użytkowników. Ponadto nie ma żadnych wpisów do plików log. OO -DODE_READONLY

7 Transakcje – zatwierdzenie, wycofanie n System przystępuje do zatwierdzenia transakcji (commit) w następujących przypadkach: 1. wykonanie instrukcji break kończącej blok transakcji; 2. wykonanie instrukcji return kończącej blok transakcji; 3. normalne zakończenie bloku instrukcji ujętych w transakcję. n Transakcja kończy się wycofaniem jeśli wystąpi jeden z poniższych warunków: 1. użytkownik jawnie wywoła instrukcję tabort (wtedy również kończymy blok transakcji); 2. nastąpi zakleszczenie; 3. z jakichkolwiek powodów transakcja mogła zostać zakończona.

8 Obiekty trwałe n Obiekt jakiejkolwiek klasy jak i obiekt typu prostego jak np.: char, short, int, long, unsigned char, unsigned short, unsigned int, unsigned long, float i double może być utworzony jako obiekt trwały. Definicja klasy, której obiekty maja być trwałe musi być poprzedzona deklaracja, która ma następująca formę: persistent class class-name; Taka deklaracja pozwala na tworzenie obiektów klasy employee o charakterze zarówno trwałym jak i ulotnym. n Jeżeli klasa ma być użyta tylko do tworzenia obiektów trwałych, wówczas zamiast poprzedniej deklaracji można zastosować deklarację klasy bezpośrednio jako klasy trwałej: n Specyfikacja klasy jako trwałej nie jest potrzebna w programie, w którym nie manipulujemy, ani nie odwołujemy się do obiektów trwałych, będących instancjami tej klasy. persistent class employee; class employee { char addr[16];... }; persistent class employee { char addr[16];... };

9 Klasa cluster n Wszystkie obiekty w bazie danych składowane są wewnątrz klastrów (w odróżnieniu od systemów relacyjnych gdzie dotyczy to tylko określonych obiektów). Domyślnie, wszystkie obiekty typu np. telefon, są składowane w domyślnym klastrze powiązanym z typem telefon. Jeżeli wszystkie obiekty typu telefon są składowane w domyślnym klastrze, wówczas klaster ten reprezentuje zasięg obiektów typu telefon. Użytkownicy mogą jednak alokować swoje obiekty w zdefiniowanych przez siebie klastrach. W przykładzie ZepsuteTelefony i Dokumentacje są wskaźnikami na klastry nazwane odpowiednio zepsute i dokumenty. database *db;... if((db=database::open("AW"))==0) {... } trans{ cluster ZepsuteTelefony("zepsute", db), Dokumentacje("dokumenty",db);... }...

10 Klastry – cechy i ograniczenia n Jeżeli zamierzamy używać własnych klastrów musimy pamiętać o ograniczeniach i ich cechach: u deklaracja klastra musi występować wewnątrz transakcji u klaster może zawierać obiekty różnych typów u wskaźnik na klaster utworzony wewnątrz transakcji jest widoczny tylko w jej zasięgu i po jej zakończeniu wszelkie odwołania do niego są błędne. Wskaźniki na klastry są bowiem, tak jak zmienne, składowane na stosie i po zakończeniu bloku, w którym zostały zadeklarowane przestają istnieć. n Jest rzeczą oczywistą, że w momencie gdy tworzymy obiekty danego typu i nie definiujemy własnego klastra, lub tworzymy je nie umieszczając ich jawnie w zdefiniowanym klastrze, trafiają one do domyślnego (wcześniej omówionego) klastra.

11 Tworzenie i usuwanie trwałych obiektów n Obiekty trwałe są tworzone i usuwane poprzez użycie operatorów pnew i pdelete. Poza tym, że operatory te dotyczą obiektów w bazie danych a nie obiektów na stosie, ich semantyka jest podobna do operatorów new i delete. Operatory pnew i pdelete nie mogą być przeciążane. To jednak nie oznacza, że nie mamy prawa przeciążać lub też tworzyć własnych konstruktorów. n Operator pnew zwraca wskaźnik do obiektu trwałego. Wskaźniki takie noszą nazwę wskaźników trwałych. Wskaźniki trwałe są deklarowane tak samo jak zwykłe wskaźniki z wyjątkiem tego, że przy ich deklaracji jest użyte określenie typu - słowo kluczowe persistent. n Obiekty trwałe są wskazywane przez trwałe wskaźniki tak samo jak obiekty będące na stosie wskazywane są przez wskaźniki ulotne.

12 Tworzenie i usuwanie trwałych obiektów (przykład) (1) n Poniższy przykład pokazuje jak można tworzyć i manipulować trwałymi obiektami: persistent class osoba{... public:... int wiek; char nazwisko[20]; }; main() {... persistent osoba *ktos; trans {... ktos = pnew osoba;... ktos->wiek=40;... pdelete ktos; } n Domyślnie pnew tworzy obiekt w domyślnej bazie danych. Baza danych w której nowo tworzony obiekt ma zostać umieszczony może być jednak podana jawnie i może być różna od domyślnej (ostatnio otwartej) : ktos = pnew osoba in db;

13 Tworzenie i usuwanie trwałych obiektów (przykład) (2) n Obiekt umieszczony w domyślnej bazie danych lub też w jawnie podanej bazie jest umieszczony w domyślnym klastrze przypisanym obiektom tego typu. Można jednak zdefiniować dla obiektu alternatywny klaster. Umieszczanie obiektów w predefiniowanych klastrach daje większa kontrolę nad ich fizycznym i logicznym rozmieszczeniem przez co uzyskujemy większą wydajność i uporządkowanie bazy danych. n Poniższy fragment pokazuje w jaki sposób możemy używać klastrów n Pojedynczy klaster może zawierać obiekty różnych typów. persistent osoba *ktos; trans { cluster osoby("osobki", db); ktos = pnew osoba in osoby; }