58255 ullman217 (2)

/. .MMKMUWt ASPEKTY JĘZYKA SQL

Transakcja rozpoczyna się od wykonywania instrukcji stanowiącej zapytanie lub inne działanie na bazie danych albo jej schemacie. W języku $QL nie ma żadnej specjalnej instrukcji rozpoczęcia transakcji. Natomiast trzeba ją w jawny sposób zakończyć. Można to zrobić na dwa sposoby:

1.    Instrukcja COMMIT zatwierdza wykonanie transakcji i stanowi ona pozytywne zakończenie transakcji. Oznacza to, że wszystkie zmiany w bazie danych, które zostały wykonane przez instrukcje wchodzące w skład transakcji, są do bazy danych wprowadzone na stałe (tzn. do momentu zatwierdzenia innych modyfikacji). Zanim nastąpi zatwierdzenie zmiany są tylko chwilowe i nie są widoczne dla innych transakcji.

2.    Instrukcja ROLL3ACK stanowi cofnięcie wprowadzonych zmian, a zatem jest to negatywny wynik transakcji. Oznacza to, że zmiany wprowadzane przez instrukcje nic są obowiązujące i stan bazy jest taki jak przed transakcją.

PRZYKŁAD 7.13

Załóżmy, że funkcja Przelew () z rys. 7.10 ma się wykonywać zawsze jako jednostkowa transakcja. Ta transakcja rozpoczyna się w wierszu 8) w chwili wczytywania salda z pierwszego konta. Jeśli test w wierszu 11) przebiegnie pozytywnie i przelew zostanie wykonany, to trzeba zatwierdzić zmiany danych, a więc trwale zapisać je w bazie. A więc przy końcu bloku if z wierszy od 12) do 17) należy umieścić dodatkową instrukcję w SQL:

EXEC SQL COMMIT;

Jeśli warunek sprawdzany w wierszu 11) okaże się fałszywy, a więc saldo na pierwszym koncie jest zbyt niskie, aby był dokonany przelew-, to trzeba cofnąć transakcję. Można to zrobić, umieszczając na końcu bloku else z wiersza 18) następującą instrukcję:

EXEC SQL R0LL3ACK;

Jednakże w tym przypadku, czyli przy wyborze tej ścieżki w programie, nie pojawiły się żadne instrukcje modyfikacji, tj. żadne zmiany chwilowe nie następują, a zatem jest zupełnie obojętne czy zastosujemy instrukcję COMMIT, Czy ROILBACK.

□

7.2.4. Transakcje tylko do odczytu

Transakcje, opisane w przykładach 7.11 i 7.12, obejmowały odczytanie, a następnie w pewnych okolicznościach zapisanie danych do bazy danych. Omawiane transakcje przypominają problem sekwencyjności. Przedstawiliśmy w przykładzie 7.11 konsekwencje jednoczesnego wywołania funkcji rezerwującej to samo miejsce w samolocie, a z kolei w przykładzie 7.12 uwidoczniono skutki awarii, która zdarza się w trakcie przetwarzania funkcji. Jednakże w przypadku transakcji, które powodują tylko odczyt danych, istnieje więcej swobody w równoległym przetwarzaniu wielu transakcji*.

PRZYKŁAD 7.14

Rozważmy funkcję, która wczytuje dane z bazy po to, by stwierdzić, czy pewne miejsce jest dostępne; jej tekst stanowi fragment z rys. 7.8 zapisany w wierszach od 1) do 11). Oczywiście bez szkody dla bazy danych możemy przetwarzać jednocześnie wiele wywołań tej funkcji. Najgorsze co może się stać, to że w trakcie odczytu dostępności miejsca inna funkcja właśnie to miejsce rezerwowała albo zwalniała. Można by zatem uzyskać informację o tym, że miejsce jest dostępne albo że jest niedostępne w pewnym niewielkim przesunięciu w czasie, ale odpowiedź ma sens.

□

Jeśli system SQL zostanie poinformowany o tym, że bieżąca transakcja jest tytko do odczytu, tzn. że jej działanie nie powoduje zmiany stanu bazy danych, to najczęściej ta informacja zostanie wykorzystana. Mimo że nie opiszemy tutaj szczegółów tego mechanizmu, to należy zapamiętać, iż umożliwia on jednoczesne przetwarzanie wielu transakcji tylko do odczytu, które działają na tych samych danych, ale z kolei blokuje dane w przypadku transakcji, które zapisują nowe w artości w bazie.

W języku SQL transakcje określa się jako tylko do odczytu w następujący sposób:

SET TRANSACTION READ ONLY;

Ta instrukcja musi wystąpić, zanim rozpocznie się transakcja. Gdyby to dotyczyło fragmentu funkcji zapisanej w wierszach od 1) do 11) na rys. 7.8, to należałoby umieścić następującą instrukcję

EXEC SQL SET TRANSACTION READ ONLY;

tuż przed wierszem 9), w który m transakcja się rozpoczyna. Umieszczenie tej deklaracji po wierszu 9) jest zbyt późne.

’ Można przedstawić pewne porównanie transakcji z kursorami. Na przykład w p. 7.1.10 zwróciliśmy uwagę na to, zc można stosować więcej równoległości w przypadku kursorów przeznaczonych tylko do c/ytania danych niz. w przypadku dowolnych kursów. Podobnie rzecz się ma z transakcjami, transakcje tylko do odczytu umożliwiają stosowanie równoległości w szers/ym zakresie niz. zwykłe transakcje.