Optimistické zamykání (optimistic locking)

Příklady z praxe

1. 01

   Úprava profilu se sloupcem version

   Dva administrátoři otevřou stejný záznam zákazníka s hodnotou version = 7. První uloží změnu telefonu, verze stoupne na 8. Druhý o chvíli později odešle svůj UPDATE s podmínkou version = 7, databáze vrátí nula změněných řádků a aplikace mu ukáže konflikt místo tichého přepsání.

   UPDATE zakaznik
   SET email = 'novy@example.com',
       version = version + 1
   WHERE id = 42 AND version = 7;
   -- vrátí 0 řádků => konflikt, načíst znovu a zopakovat

2. 02

   REST API s ETag a If-Match

   Klient si stáhne dokument a spolu s ním hlavičku ETag s hodnotou "a91f". Při ukládání pošle PUT s hlavičkou If-Match: "a91f". Pokud mezitím uložil někdo jiný, server má novou hodnotu ETag a odpoví 412 Precondition Failed. Klient si stáhne aktuální verzi a nabídne uživateli porovnání.

   PUT /api/dokumenty/17 HTTP/1.1
   If-Match: "a91f"
   Content-Type: application/json
   
   {"nadpis": "Upravený nadpis"}
   
   HTTP/1.1 412 Precondition Failed

Časté omyly

MýtusOptimistické zamykání vlastně nic nezamyká, takže data nechrání.

Ve skutečnostiOptimistické zamykání chrání proti ztracené aktualizaci stejně spolehlivě jako zámek, jen konflikt řeší až při zápisu. Podmínka na verzi se vyhodnocuje atomicky uvnitř databáze, takže dva souběžné zápisy nemohou uspět oba.

MýtusKdyž použiju optimistické zamykání, nemusím řešit opakování transakce.

Ve skutečnostiOptimistické zamykání bez logiky opakování jen přesouvá chybu k uživateli. Aplikace musí konflikt zachytit, znovu načíst aktuální stav a operaci buď automaticky zopakovat, nebo nabídnout sloučení změn.

MýtusOptimistické zamykání je vždy rychlejší než pesimistické.

Ve skutečnostiOptimistické zamykání vyhrává jen při nízké míře sporu. U horkého řádku, o který se pere mnoho zapisujících, převáží náklady na opakované neúspěšné pokusy a pesimistický zámek bývá výrazně efektivnější.

Časté dotazy

Jak poznám, že mám v aplikaci nastavit optimistické nebo pesimistické zamykání?

Rozhodujícím ukazatelem je míra sporu o konkrétní řádek. Optimistické zamykání se hodí tam, kde souběžná editace téhož záznamu je výjimkou: uživatelské profily, objednávky, dokumenty, konfigurace. Pesimistický zámek dává smysl u sdíleného čítače, posledního kusu na skladě nebo účetního zůstatku, kde se o stejná data pere mnoho zapisujících naráz. Praktický postup je začít optimisticky a měřit, jak často zápis selhává na neshodu verze. Pokud podíl konfliktů roste nad jednotky procent, přechod na zámek nebo na atomickou operaci přímo v databázi obvykle pomůže víc než ladění opakování.

Kolikrát se má transakce po konfliktu automaticky zopakovat?

Automatické opakování by mělo mít pevný strop, typicky tři až pět pokusů, a mezi pokusy exponenciálně rostoucí prodlevu s náhodným rozptylem. Bez stropu se pod zátěží roztočí lavina opakování, která zhoršuje přesně tu situaci, kterou má řešit. Automaticky lze opakovat jen operace, které nemají vedlejší efekty mimo databázi, nebo které jsou idempotentní: odeslání e-mailu ani platbu nelze slepě zopakovat. Konflikt způsobený lidskou editací se opakovat nemá vůbec, tam patří zobrazení rozdílu a rozhodnutí uživatele.

Funguje optimistické zamykání i napříč více tabulkami?

Optimistické zamykání se přirozeně váže k jednomu záznamu, ale lze ho rozšířit na agregát. Běžný postup je držet sloupec s verzí na kořenové entitě, například na hlavičce objednávky, a zvyšovat ho i při změně podřízených položek. Zápis pak kontroluje jedinou verzi a celý agregát se chová jako jedna jednotka konzistence. Podmínkou je, že všechny změny proběhnou v jedné databázové transakci. Bez toho hrozí, že část zápisu projde a část selže na neshodě verze.

Je hlavička ETag skutečně optimistické zamykání, nebo jde jen o cache?

Hlavička ETag plní obě role podle toho, s jakou podmíněnou hlavičkou se kombinuje. Ve spojení s If-None-Match slouží k ověření platnosti mezipaměti a šetří přenos dat. Ve spojení s If-Match u metod PUT, PATCH a DELETE jde o plnohodnotné optimistické zamykání: server zápis provede jen tehdy, když se reprezentace od odeslané hodnoty neliší, jinak vrátí stavový kód 412 Precondition Failed. Rozdíl je tedy v použití, nikoli v samotné hlavičce.

Zdroje

1. PostgreSQL Documentation: Concurrency Control(otevře se v novém okně)PostgreSQL Global Development Group
2. RFC 9110: HTTP Semantics(otevře se v novém okně)IETF, 2022
3. ETag - HTTP(otevře se v novém okně)MDN Web Docs
4. Optimistic concurrency control(otevře se v novém okně)Wikipedia

Související pojmy

• DeadlockDeadlock je stav, kdy se dva nebo více procesů, vláken nebo transakcí navzájem blokují, protože každý drží prostředek, který potřebuje někdo další. Výpočet pak nemůže pokračovat bez zásahu plánovače, databáze nebo aplikace, typicky u zámků, mutexů, souborů či řádků v databázi.
• IdempotenceIdempotence je vlastnost operace, u které opakované provedení se stejnými vstupy skončí ve stejném stavu jako provedení jediné. Je to základní pojistka proti dvojímu zaúčtování, když se požadavek kvůli výpadku sítě odešle dvakrát.
• Race conditionRace condition je chyba souběhu, při níž správnost programu závisí na náhodném pořadí nebo načasování operací nad sdíleným stavem. Projeví se typicky ve vláknech, asynchronním kódu, databázových transakcích nebo distribuovaných systémech, kde dvě části programu čtou a mění stejná data bez dostatečné synchronizace.
• Skladová dostupnostSkladová dostupnost je informace o tom, kolik kusů daného produktu je možné právě teď prodat a za jak dlouho je zákazník dostane. V e-shopu se skládá z fyzického počtu kusů na skladě, z rezervací rozpracovaných objednávek a z termínu naskladnění, takže se liší od pouhého čísla ve skladovém systému.
• 3D model3D model je digitální reprezentace objektu nebo prostoru ve třech rozměrech, složená z geometrie, materiálů a často i textur, animací či fyzikálních vlastností. Používá se v hrách, filmech, průmyslovém návrhu, architektuře, e-commerce i simulacích, kde software z modelu počítá zobrazení nebo další data.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• Adresa v pamětiAdresa v paměti je číslo, kterým procesor jednoznačně označuje konkrétní buňku operační paměti, obvykle jeden bajt. Program pomocí adresy říká, odkud má data načíst nebo kam je zapsat. Adresy tvoří souvislý číselný rozsah, jehož velikost určuje šířka adresní sběrnice a architektura, typicky 32 nebo 64 bitů.