Pro zajištění konzistence dat je třída CMemoryDb, která implementuje databázi měst, plánů a autobusů v operační paměti vybavena zámky typu více čtení/jeden zápis pomocí instancí třídy CReadWriteLock. Díky tomu je zajištěno, že volání každé veřejné metody je atomickou operací, tj. předaná data se zpracují najednou a návratové hodnoty odrážejí odpovídající platný stav, který nemůže být narušen souběžným voláním metod z dalších vláken.
Ochrana je rozdělena do tří okruhů či úrovní:
- celá databáze,
- subsystém měst, subsystém plánů, subsystém autobusů,
- jednotlivá města, plány a autobusy.
Situaci zachycuje následující obrázek.
Unikátní přístup k celé databázi (jakoby pro zápis) je potřeba pouze v případě provádění zálohy databáze, všechny ostatní operace využívají sdílený přístup (pro čtení) - purpurová barva.
Druhý okruh (ochrana některého ze subsystémů) zajišťuje ve výlučném režimu konzistenci kontajnerů - např. pro města při přidávání a mazání měst a aktualizaci indexů a aliasů - modrá barva na obrázku. Při ostatních operacích (vyhledávání města, práce s konkrétním městem) je dostatečný přístup sdílený.
Jednotlivé objekty typu CCity, CPlan nebo CBus chrání zámky třetí úrovně - na obrázku vyznačeno barvou červenou. Jedinečný přístup vyžaduje například provádění rezervací sedadel, naopak např. pro získávání počtu linek pro konkrétní město je dostatečný sdílený přístup. Pro čtení konstatních informací (např. plán autobusu) není třeba žádná ochrana na úrovni třídy, neboť tato data se po dobu životnosti nemohou měnit.
Takže kupříkladu pro vykonání operace rezervace sedadla je nutné získat
- přístup pro čtení do celé databáze (okruh 1),
- přístup pro čtení do subsystému autobusů - vyhledání autobusu (okruh 2) a
- přístup pro zápis do požadovaného autobusu (okruh 3).
Zámek pro ochranu celé databáze je přímo zděděnou součástí CMemoryDb, pro subsystémy jsou instance zámků jejími privátními položkami. Zamykání jednotlivých objektů si obstarávají přímo třídy CCity, CPlan a CBus, které dědí od CReadWriteLock.
Teprve zátěžové testy na velké databázi a s velkým množstvím současných přístupů by ukázaly, zda navržené řešení je optimální. Vždy je třeba hledat vhodný kompromis mezi granularitou uzamykání a rychlostí přístupu k položce. Na jedné straně průchod každým zámkem stojí nějaký čas, na straně druhé umožňuje případné paralelní zpracování dotazů. Kromě jiného bude jistě záležet i na konkrétním hardware (např. počtu nezávislých procesorových jader).
