Konkurenční přístup k datům - zamykací mechanismy, díl druhý

V předchozím díle jsem popisoval optimistické zamykání na datové úrovni, v tomto díle popíšu pesimistické zamykání a také zmíním další možný způsob řešení konkurenčního přístupu k datům - plně izolované transakce.

Pesimistické zamykání

Tento způsob zamykání již předem počítá s tím, že bude docházet ke konkurenčním přístupům k datům, a proto si každá transakce zamkne svá data a nepustí je dokud data nebudou úspěšně změněna nebo pokud se neprovede roll-back transakce. Tím je zaručeno, že data během transakce nikdo jiný nezmění, a že se aktualizace vždy povede. Také je zaručena konzistence čtených dat v rámci jedné transakce.

Pesimistické zamykání na úrovni dat je řešeno přímo databázovými stroji, např. Oracle používá SELECT FOR UPDATE.

Výhody: není potřeba měnit datový model, zaručuje konzistentní data pro čtení, zaručuje, že jiná transakce nezmění zamknutá data, lepší než izolované transakce - menší nároky na zajištění konzistence dat, menší pravděpodobnost dead-locku.

Nevýhody: všechny potencionálně konfliktní transakce musejí používat stejný přístup nad danou datovou jednotkou, výrazně snížena výkonnost, při častém použití se zvyšuje pravděpodobnost deadlocku (jedna transakce čeká na druhou až uvolní svá data), použití SELECT FOR UPDATE má svá určitá omezení, ne všechny perzistentní Java ORM nástroje tento přístup umožňují, omezená použitelnost cache.

Použití: vhodné pro aplikace, kde je potřeba mít zaručenou konzistentnost čtených dat, kde nemáme možnost použít jiný typ zamykání.

Plně izolované transakce

Pokud budeme používat transakce, které jsou od sebe vzájemně izolovány pak databázový stroj zaručí, že výsledek spuštění více transakcí v jeden moment bude stejný, jako kdyby se jednotlivé transakce spustily postupně za sebou. Bohužel tímto přístupem velice trpí výkonnost a škálovatelnost databázového stroje.
Pro řadu případů je možné použít slabší úrovně izolace - REPEATABLE READ nebo READ COMMITTED.

Výhody a nevýhody jsou zřejmé - jednoduché na použití, zabraňuje většině problémů s konkurenčním přístupem k datům, ale za cenu big overhead.

Použití bude tam, kde ztráta výkonnosti je akceptovatelná nebo tam, kde je naprosto podstatná konzistence čtených dat.


Já osobně preferují mezi ORM nástroji Hibernate, proto ještě uvádím odkaz na možnosti vymezení transakcí resp. řešení konkurenčního přístupu v tomto nástroji.

V příštím a posledním díle se budu věnovat offline zamykacím mechanismům.