Blokowanie optymistyczne to strategia, w której czytasz rekord, zapisujesz numer wersji (innymi metodami do tego są daty, znaczniki czasu lub sumy kontrolne/hashe) i sprawdzasz, czy wersja nie uległa zmianie przed ponownym zapisaniem rekordu. Kiedy zapisujesz rekord z powrotem, filtrujesz aktualizację według wersji, aby upewnić się, że jest niepodzielna. (tj. nie został zaktualizowany między sprawdzeniem wersji i zapisaniem rekordu na dysku) i zaktualizuj wersję jednym uderzeniem.
Jeśli rekord jest brudny (tj. Inna wersja niż twoja), przerywasz transakcję, a użytkownik może ją ponownie uruchomić.
Ta strategia jest najbardziej odpowiednia do systemów o dużej objętości i architektur trójwarstwowych, w których niekoniecznie utrzymujesz połączenie z bazą danych podczas sesji. W tej sytuacji klient nie może faktycznie utrzymywać blokad bazy danych, ponieważ połączenia są pobierane z puli i możesz nie używać tego samego połączenia z jednego dostępu do drugiego.
Blokowanie pesymistyczne ma miejsce, gdy blokujesz rekord do wyłącznego użytku, dopóki nie skończysz z nim. Ma znacznie lepszą integralność niż optymistyczne blokowanie, ale wymaga ostrożności przy projektowaniu aplikacji, aby uniknąć zakleszczeń. Aby użyć pesymistycznego blokowania, potrzebujesz albo bezpośredniego połączenia z bazą danych (jak to zwykle bywa w przypadku dwuwarstwowej aplikacji typu klient-serwer) lub dostępnego z zewnątrz identyfikatora transakcji, który może być używany niezależnie od połączenia.
W tym drugim przypadku otwierasz transakcję z TxID, a następnie ponownie łączysz się przy użyciu tego ID. DBMS utrzymuje blokady i pozwala na przywrócenie sesji poprzez TxID. W ten sposób działają transakcje rozproszone korzystające z protokołów zatwierdzania dwufazowego (takich jak transakcje XA lub COM+).
