Skip to content

Locking Model

Jump to bottom
ppodsednik edited this page Feb 25, 2026 · 5 revisions

Locking Model v Akubra Repository

Tato stránka popisuje model distribuovaného zamykání, který Akubra používá k zajištění konzistence dat při souběžném přístupu více instancí aplikace k jednomu repozitáři.

Zamykání je klíčovou součástí návrhu Akubry, ale je používáno cíleně a úsporně, aby neomezovalo výkon čtecích operací.

1. Proč je zamykání potřeba

Akubra je typicky provozována v prostředí, kde:

  • běží více instancí aplikace (např. cluster Tomcatů),
  • všechny instance pracují nad stejným filesystemovým repozitářem,
  • paralelně probíhá ingest, aktualizace i čtení dat.

Bez koordinace by mohlo docházet k:

  • souběžnému zápisu do FOXML souboru,
  • nekonzistenci datastreamů,
  • porušení relační integrity (RELS-EXT),
  • nekonzistentnímu stavu processing indexu.

Cílem zamykání je tedy:

  • ochrana kritických zápisových operací,
  • zachování konzistence dat,
  • minimální dopad na výkon.

2. Základní filozofie zamykání

Zamykací model Akubry vychází z následujících principů:

  • zamykání je povinné pouze pro kritické operace,
  • běžné čtecí operace nejsou zamykány,
  • zápisové operace mají zamykání vestavěné v Akubra core,
  • aplikace může explicitně zamykat větší logické celky.

Tento přístup:

  • maximalizuje paralelismus při čtení,
  • chrání repozitář tam, kde je to nutné,
  • umožňuje aplikaci převzít kontrolu nad rozsahem zámku.

3. Hazelcast Locks Server

Role Hazelcastu

Akubra používá externí službu:

pro implementaci distribuovaných pojmenovaných zámků.

Hazelcast zajišťuje, že:

  • zámky jsou sdílené mezi různými JVM,
  • zámky fungují napříč servery,
  • chování je deterministické i při paralelním přístupu.

Povinnost použití

  • Neni povinny pro jednoduche aplikace bez paralelniho pristupu k repository
  • v produkčním prostředí je jeho použití považováno za povinné:
  • Hazelcast locks server je nutný pro zápisové operace,
  • bez něj není garantována konzistence repozitáře,

4. Granularita zámků

Zámky jsou typicky:

  • vázané na PID objektu,
  • pojmenované deterministickým způsobem.

To znamená, že:

  • různé objekty lze zapisovat paralelně,
  • tentýž objekt je chráněn proti souběžným zápisům.

V některých případech (např. ingest větších struktur) je však žádoucí zamykat:

  • více objektů najednou,
  • nebo celý logický celek.

To umožňuje explicitní API popsané níže.

5. Vestavěné zamykání v Akubra core

Akubra core automaticky používá zámky při:

  • ingestu nových objektů,
  • aktualizaci FOXML objektů,
  • změnách datastreamů,
  • operacích ovlivňujících processing index.

Vývojář aplikace:

  • nemusí explicitně řešit zamykání pro běžné zápisové operace,
  • může se spolehnout na konzistenci garantovanou Akubrou.

6. Explicitní API pro zamykání

Rozhraní AkubraRepository poskytuje metody:

  • doWithReadLock(...)
  • doWithWriteLock(...)

Tyto metody umožňují aplikaci:

  • obalit vlastní logiku zámkem,
  • pracovat s více objekty atomicky,
  • řídit rozsah kritické sekce.

Typické použití

  • dávkový ingest více objektů,
  • konzistentní aktualizace struktury dokumentu,
  • kombinace čtení a zápisu nad více PID.

Zámky získané těmito metodami:

  • jsou reentrantní,
  • lze je bezpečně vnořovat,
  • jsou sdílené s interními zámky Akubra core.

7. Výkonové dopady

Zamykání v Akubře je navrženo tak, aby:

  • neovlivňovalo běžné čtení,
  • minimalizovalo dobu držení zámku,
  • umožňovalo vysoký stupeň paralelismu.

Doporučení:

  • zamykat pouze nezbytný kód,
  • držet zámek co nejkratší dobu,
  • nepoužívat write lock pro čistě čtecí operace.

8. Typické chyby a doporučení

Časté chyby

  • příliš hrubé zamykání celého repozitáře,
  • zamykání čtecích operací bez důvodu,
  • dlouhotrvající operace uvnitř write locku.

Doporučený přístup

  • spoléhat se na core Akubry pro běžné operace,
  • explicitní zamykání používat pouze tam, kde je to nutné,
  • myslet na zamykání už při návrhu workflow.

Clone this wiki locally