Bezpečné transakce při zakládání uživatelů/účastníků/účastí

Closes #314 (closed):

Pokud organizátor odešle POST na přidání nového účastníka soutěže dvakrát rychle po sobě (třeba kvůli nějakému automatickému retry po rozpadu spojení), dvě různé DB transakce se snaží založit uživatele se stejným loginem. Jedna z nich selže na unikátnosti sloupce email.

V defaultní úrovni izolace transakcí (READ COMMITTED) to nemá žádné hezké řešení. Nepomůže SELECT ... FOR UPDATE, jelikož ten zamyká pouze nalezené řádky, nikoliv neexistenci dalších řádků vyhovujících podmínce.

Co by se dalo dělat:

(1) Zvýšit úroveň izolace aspoň na READ REPEATABLE. To vyřeší problém, ale současně může začít víceméně jakákoliv zapisující transakce failovat. Vyžadovalo by dopsat retry do prakticky všech míst v OSMO, kde je nějaký commit.

(2) Retryovat specificky transakce na zakládání užívatelů (a účastí apod.). Tohle nejde snadno, jelikoz jsou i součástí dlouho běžících transakcí v importech (zatím jsme se snažíli, aby byl celý import atomický a v případě selhání se celý rollbackoval). To by možná mohly vyřešit subtransakce.

(3) Zamykat celou tabulku s uživateli, než na ní provedeme první SELECT. To by asi vyřešilo problém, ale byl by potřeba zápisový zámek, takže by paralelně nemohla běžet žádná čtení. A také by se to potenciálně mohlo deadlockovat (potřebujeme v jedné transakci postupně lock na uživatele, účastníky a účasti a locky platí až do konce transakce).

(4) Používat INSERT ... ON CONFLICT <něco>. To vypadá bezpečně, jen to není moc pohodlné, zejména proto, že s tím nepočítá ORM, takže je potřeba dělat všechno ručně.

Zatím jsem zvolil (4), protože mi přijde, že to změny udržuje lokální a funguje i s dlouhými transakcemi při importu. Výhledově bych se ale chtěl zamyslet nad tím, jak takové věci řešit co nejuniverzálněji a nejpohodlněji.

Viz též #313.

Pročetl jsem si merge request, kód vypadá dobře (na chvíli mě zmátlo, jak je zamýšlený while cyklus na získávání participation, nebylo na první pohled intuitivní, že happy path očekává právě jeden retry :)).

Ohledně toho, co s tím dělat: Dělat velké globální zamykání (ať už zvýšením míry izolace nebo jiným zámkem třeba na straně aplikace) mi přijde nešikovné, stalo by se z toho úzké hrdlo. Řešení s ON CONFLICT na místech, kde hrozí race condition, mi přijde asi nejlepší.

Díky, tak já přidám ještě pár dalších ON CONFLICT. Nasadím to, až se přežene aktuální vlna registraci do Z-ek.

added 3 commits

• eb426abc - Registrace používá find_or_create_user
• 9b14c037 - Registrace ošetřuje kolize při změně e-mailu
• 273a054b - Účastnický submit ošetřuje kolize

Compare with previous version

mentioned in issue #224

approved this merge request

added 27 commits

• 273a054b...1c1c77a2 - 21 commits from branch devel
• 1a1f02fe - Revert "Logování: Připsáno několik flushů, aby byla data kompletní"
• 37185c2f - Pár logovacích hlášek přeloženo do češtiny
• 6aff4e91 - Bezpečné transakce při zakládání uživatelů/účastníků/účastí
• 66692424 - Registrace používá find_or_create_user
• 1195ddeb - Registrace ošetřuje kolize při změně e-mailu
• fc1f361a - Účastnický submit ošetřuje kolize

Compare with previous version

merged

mentioned in commit d7c9ed8c