Aktualności i artykuły

Opublikowano: 19 kwietnia 2016
Kategoria wpisu: poradnikiprogramowanie

Transakcyjność

Kontrola transakcji (commitment control) to potężny środek pozwalający na zachowanie integralności bazy danych DB2 w systemie AS/400. Transakcyjność daje możliwość wykonywania aktualizacji zbioru lub zbiorów bazy danych bez definitywnego ich zastosowanie do czasu aż nastąpi właściwe potwierdzenie wykonanych zmian (commit). Alternatywą przedstawionego scenariusza jest możliwość wycofania wykonanych zmian (tzw. roll back), i powrót do stanu wyjściowego, sprzed ich wprowadzenia.

Każdy programista, który kiedykolwiek wykorzystywał wbudowany SQL (embedded SQL) w swoich programach świetnie kojarzy parametr COMMIT, który należy podać przy kompilacji źródła CRTSQL*.

Transakcyjność często była i jest pomijana ze względu na brak kronikowania zbiorów bazy danych (journaling). Brak kronikowania zbiorów zwykle wynikał z kosztów związanych z zapewnieniem odpowiednio większej przestrzeni dyskowej a także koniecznością administrowania dziennikami/kronikami.Starsze wersję języka RPG nie pozwalały na opcjonalne użycie kontroli transakcji w programie, a zakres jej stosowania dotyczył aktualnego zadania.

Koszty pamięci dyskowych są obecnie znikome a wiele systemów korzysta z rozwiązań High Availability (HA), które działają w oparciu o kronikowanie. Język RPG od wersji IV pozwala na opcjonalne użycie kontroli transakcji a zakres działania można ograniczyć wewnątrz zadania, więc nic nie stoi na przeszkodzie aby obsługę transakcji dołączyć do oprogramowania.

Kronikowanie

Aby móc korzystać z możliwości jakie daje kontrola transakcji wymagane jest kronikowanie zbioru bazy danych, który taką kontrolą ma być objęty.
Idea kronikowania polega na zapewnieniu możliwości odtworzenia bazy danych do stanu w jakim była w wybranym momencie. Gdy plik jest kronikowany, manager bazy danych rejestruje kopię rekordu pliku bazy danych przy każdej jego aktualizacji (dodaniu, aktualizacji lub usunięciu). Oznacza to, że system posiada kopię każdej zmiany w pliku podłączonym do kroniki i w przypadku utraty danych może odtworzyć wszystkie wykonane zmiany.

Mechanizm kronikowania składa się z dwóch obiektów: kroniki (journal) i dziennika (journal receiver). W momencie gdy następuje zmiana w pliku bazy danych, kopia zmienianego rekordu wędruje do kroniki, która następnie „składuje” informacje w dzienniku. Gdy dziennik się zapełni, można go zeskładować na zewnętrznym nośniku danych a do kroniki podłączyć kolejny dziennik.
Journalling
Jak sprawdzić czy wybrany plik bazy danych jest kronikowany ? Wystarczy użyć komendy DSPOBJD i odnaleźć parametry opisujące aktualny stan kronikowania dla wybranego obiektu.

DSPOBJD OBJ(plikBD)  OBJTYPE(*FILE) DETAIL(*FULL)
Kronikowanie pliku

Kronikowanie pliku

Jeśli plik  jest kronikowany, pozostaje tylko zaimplementować obsługę transakcyjności w kodzie programów, w przeciwnym wypadku należy utworzyć dla niego kronikę oraz dziennik.

Dziennik tworzymy za pomocą komendy Create Journal Receiver

CRTJRNRCV JRNRCV(dziennik)

Kronika zaś tworzona jest komendą Create Journal  i w momencie jej definiowania „podłączamy” do niej dziennik.

CRTJRN JRN(kronika) JRNRCV(dziennik)

Aby zapewnić kronikowanie wybranego pliku bazy danych wykorzystujemy komendę Start Journal Physical File

STRJRNPF FILE(plikBD) JRN(kronika)

W jaki sposób powinna wyglądać implementacja transakcyjności w przykładowym programie, już niedługo…

 

 

^