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

Každý asi ví, že konkurenční přístup k datům je nutné řešit, ať už na datové nebo aplikační úrovni. Mám ovšem tu zkušenost, že většina kolegů tento problém řeší až v době implementace případu užití, což si myslím, že už je trochu pozdě. Přístup k datům resp. zvolený zamykací mechanismus ovlivňuje návrh samotné aplikace (datový model nebo aplikaci samotnou) a proto by způsob přístupu k datům měl být vyjasněn již v době analýzy a zohledněn v návrhu aplikace.
Rád bych tedy v sérii několika článků zmínil základní způsoby řešení konkurenčního přístupu k datům - ať už na úrovni datové nebo aplikační.

Optimistické zamykání

Navzdory svému jménu vlastně o žádné zamykání nejde. Transakce přistupují k datům bez nějakého omezení, pouze při updatu se ověřuje, zda data nebyla v průběhu transakce změněna jinou transakcí od doby, kdy se data načetla. V případě kolize je nutné transakcí vrátit (roll-back).
Kontrola změny dat se může řešit pomocí:

• evidence verze. Pro tuto variantu je nutné přidat nový speciální sloupec do tabulky pro evidenci verze. Při každé změně hodnoty se zvýší verze a pak je jednoduché zjistit, zda došlo ke změně nebo nikoliv.


• evidence času poslední změny. Víceméně totožné jako předchozí varianta, ale místo verze se eviduje timestamp poslední změny.


• porovnání nové a původní hodnoty. Velké výhoda tohoto přístupu je ta, že není nutné přidávat žádný sloupec, tedy vhodné pro systémy, kde nemůžeme provádět úpravy v datovém modelu.

Většina ORM nástrojů minimálně jeden z uvedených způsobů podporuje a je pouze otázkou konfigurace, jaká implementace se použije.

Výhody: snadná implementace, nenáročná kontrola změny dat a roll-back pouze v případě konfliktu

Nevýhody: všechny konkurentní transakce (myšleno nad jednou datovou jednotkou, např. tabulkou) musejí používat optimistické zamykání, není vždy možné provádět změny v datovém modelu a tedy přidávat nové sloupce (není možné vždy použít třetí variantu ověřování, např. problémy s null hodnotami, desetinná čísla), není zaručena konzistence čtených dat.

Použití: vhodné pro aplikace, kde máme datový model pod kontrolou, kde nám moc nevadí nekonzistentnost dat při čtení a hlavně tam, kde nám nevadí, když se aktualizace dat neprovede. Pokud budu v UI mít složitý formulář nebo průvodce přes několik obrazovek, tak pak bych optimistické zamykání určitě nepoužil, protože uživatel by asi nebyl moc šťastný, když by si po několika minutách vkládání dat do formulářů přečetl hlášku, že data nelze uložit.

V příštím díle se zmíním o pesimistickém zamykání a dalších možnostech řešení konkurenčního přístupu k datům.