Pro zajištění konzistence dat je třída MemoryDb, 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 ReaderWriterLockSlim. 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.

Zámky pro vícenásobný přístup

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 City, Plan nebo Bus 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).

Všechny zámky jsou privátními položkami odpovídajících tříd. Zamykání jednotlivých objektů si obstarávají přímo třídy City, Plan a Bus.

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).