Jedná se o dva komentáře vkládané se stejným content_id. Pouhým vložením komentáře dojde k odblokování SHARE zámku na řádku obsahu, aby se zastavila další transakce mazání tohoto řádku, dokud nebude dokončena první transakce.
Spouštěč však poté upgraduje zámek na EXCLUSIVE, což může být zablokováno souběžnou transakcí provádějící stejný proces. Zvažte následující sled událostí:
Txn 2754 Txn 2053
Insert Comment
Insert Comment
Lock Content#935967 SHARE
(performed by fkey)
Lock Content#935967 SHARE
(performed by fkey)
Trigger
Lock Content#935967 EXCLUSIVE
(blocks on 2053's share lock)
Trigger
Lock Content#935967 EXCLUSIVE
(blocks on 2754's share lock)
Takže- uváznutí.
Jedním z řešení je okamžitě přijmout výhradní zámek na řádku obsahu před vložení komentáře. tj.
SELECT 1 FROM content WHERE content.id = 935967 FOR UPDATE
INSERT INTO comment(.....)
Dalším řešením je jednoduše se tomuto vzoru „počtů uložených v mezipaměti“ úplně vyhnout, kromě případů, kdy můžete prokázat, že je to nezbytné pro výkon. Pokud ano, zvažte ponechat počet uložených v mezipaměti jinde než v tabulce obsahu – např. vyhrazený stůl pro pult. To také sníží aktualizační provoz tabulky obsahu pokaždé, když je přidán komentář. Nebo možná jen znovu vyberte počet a použijte memcached v aplikaci. Není možné obejít skutečnost, že kdekoli uložíte tento počet uložený v mezipaměti, bude škrtícím bodem, musí být bezpečně aktualizován.