Warto na wstępie wspomnieć, iż terminy pesymistyczne i optymistyczne blokowanie dotyczą obsługi transakcji na poziomie aplikacji (to że wykorzystują do tego także bazy danych to jest już inna para kaloszy). W dużym skrócie – pesymistyczne blokowanie wykorzystuje bazuje na jawnych blokadach w bazach danych (SELECT … FOR UPDATE), podczas gdy optymistyczne blokowanie opiera się na wersjach rekordów w bazie danych (często w oparciu o MVCC).
Pesymistyczne blokowanie
Pesymistyczne blokowanie wykorzystuje natywne mechanizmy bazodanowe – klauzula FOR UPDATE:
BEGIN;
SELECT * FROM Users WHERE sex = 'M' FOR UPDATE;
UPDATE Users SET sex = 'Male' WHERE sex = 'M';
COMMIT;Warto zastosować to rozwiązanie jeśli istnieje duże prawdopodobieństwo równoległych edycji rekordu. Stąd też nazwa – pesymistyczne – zakładamy pesymistycznie, że będzie duże zainteresowanie danym rekordem.
Optymistyczne blokowanie
Optymistyczne blokowanie jest też często nazywane optymistycznym zarządzaniem współbieżnością. Ponieważ nie ma tutaj tak naprawdę, żadnego blokowania – wszystko jest oparte o wersje rekordów (z wykorzystaniem natywnego mechanizmu MVCC lub też nie):
Jak widać na powyższym diagramie – pierwszy użytkownik odczytuje rekord z tabeli Users i dostaje rekord wraz z wersją. Chwilę później drugi użytkownik dokonuje aktualizacji tego samego rekordu – z tą samą wersją (…WHERE VERSION = 1…). Następnie użytkownik pierwszy próbuje dokonać aktualizacji wcześniej odczytanego rekordu (z wersją 1). Niestety w tym momencie nie ma już rekordu w wersji pierwszej (…WHERE VERSION = 1…), więc dostajemy wyjątek.
Warto korzystać z tego rozwiązania, gdy przewidujemy, rzadkie aktualizacje tych samych rekordów.
Obsługa wyjątków
Należy pamiętać, że optymistyczne blokowanie, w przeciwieństwie do pesymistycznego, wymaga obsługi wyjątków (patrz diagram wyżej). Obsługa ta, będzie zależała od logiki biznesowej aplikacji.