INFO
Sylabus
Transakcje w bazach danych
1. Po co transakcje? - Współbieżność
2. Po co transakcje? - Przeciwdziałanie awariom
3. Transakcja: jednostka działalności systemu
4. Przykładowa transakcja
5. Kryterium poprawności transakcji
6. Implementacja szeregowalności poprzez zamki
7. Zakleszczenie
8. Walka z zakleszczeniem
9. Metody bez zakleszczeń oparte na stemplach czasowych
10. Metody optymistyczne
11. Ziarnistość mechanizmu transakcji
12. Zmienna ziarnistość
13. Typy awarii i reakcje na awarie
14. Odtwarzanie po awarii - środki, terminy
15. Odtwarzanie po zerwaniu
16. Podstawowe algorytmy z zamkami
17. Komendy w SQL do przetwarzania transakcji
18. Zagnieżdżone transakcje
19. Przykład zagnieżdżonej transakcji
20. 2PC w systemach rozproszonych
21. Długie transakcje (transakcje projektowe)
22. Podsumowanie
Skorowidz
Wyście:
Wyklad VI. Wprowadzenie do transakcji w bazach danych (KURS SSR)
I II III IV V VI VII VIII IX X XI XII XIII XIV
« poprzedni punkt   następny punkt »

17. Komendy w SQL do przetwarzania transakcji

Dowolne zdanie select, insert, update, delete, create rozpoczyna transakcję, o ile nie była ona już przez tę transakcję rozpoczęta.

Transakcja trwa aż do do wydania komendy COMMIT (potwierdzającej), ABORT lub ROLLBACK (zrywającej, cofającej). Transakcja może objąć dowolną liczbę zdań select, insert, update, delete, create i innych.

Komenda SAVEPOINT<nazwa> oznacza zapamiętanie stanu pod określoną nazwą. ABORT TO<nazwa> oznacza odtworzenie stanu.

SQL ma także inny kwiatek określany jako “isolations levels” (poziomy izolacji). Idea jest słuszna: dla pewnych sytuacji warunek pełnej izolacji okazuje się zbyt mocny.

Np. byłoby prawie niemożliwe zrobienie raportu operacji na koniec dnia, jeżeli system byłby w ciągłym ruchu, ponieważ zawsze jakieś dane byłyby zablokowane. Operacja by “utykała” na każdym kroku, szef byłby mocno wkurzony, a biedny programista oberwałby cięgi za nie swoje grzechy...

Osłabienie izolacji jest więc czasami konieczne, ale powinno to być traktowane wyjątkowo, ze specjalnym statusem, ze specjalnymi środkami bezpieczeństwa. Rozwiązanie SQL jest krytykowane jako dające programiście zbyt wiele “brudnych” możliwości.


18. Zagnieżdżone transakcje

Czy mają sens?
C.J.Date argumentuje, że nie mają.
Reszta świata (wraz ze mną) uważa, że mają.

Powody: ułatwienie programowania, dostarczenie nowego mechanizmu abstrakcji.
Programista może kilka transakcji zamknąć w jedną większą bez zmiany tekstu programu.
Programista może większą transakcję rozbić na mniejsze bez zmiany koncepcji programu.

Dwie filozofie:
  1. Zagnieżdżona transakcja jest potwierdzana wyłącznie dla swojej macierzystej transakcji, przez co aktualizacje zrobione przez pod-transakcję stają się widoczne dla innych pod-transakcji. Zamki pod-transakcji są dziedziczone przez jej mamusię. Ostateczne potwierdzenie pod-transakcji i zwolnienie zamków następuje po potwierdzeniu transakcji stojącej najwyżej w hierarchii.

  2. Każda pod-transakcja po potwierdzeniu bezpośrednio wprowadza zmiany do bazy danych. Zamki nie są dziedziczone (są zwalniane). Ale każda pod-transakcja posiada bliźniaczą pod-transakcję kompensującą, która określa co robić, jeżeli mamusia nie zostanie potwierdzona. Ta filozofia jest także określana jako saga.

« poprzedni punkt   następny punkt »