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.