Това са два коментара, които се вмъкват с един и същи content_id. Самото вмъкване на коментара ще премахне заключването за СПОДЕЛЯНЕ на реда със съдържание, за да спре друга транзакция, изтривайки този ред, докато първата транзакция не приключи.
След това обаче тригерът продължава да надгражда заключването до ЕКСКЛУЗИВНО и това може да бъде блокирано от едновременна транзакция, изпълняваща същия процес. Помислете за следната последователност от събития:
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)
И така - задънена улица.
Едно решение е незабавно вземете изключително заключване на реда със съдържание преди вмъкване на коментара. т.е.
SELECT 1 FROM content WHERE content.id = 935967 FOR UPDATE
INSERT INTO comment(.....)
Друго решение е просто да избегнете напълно този модел "кеширани брои", освен когато можете да докажете, че е необходим за производителността. Ако е така, помислете за запазване на кешираното преброяване някъде, различно от таблицата със съдържание-- напр. специална маса за тезгяха. Това също така ще намали трафика за актуализиране към таблицата със съдържание всеки път, когато се добави коментар. Или може би просто изберете отново броя и използвайте memcached в приложението. Няма как да заобиколите факта, че където и да съхранявате този кеширан брой ще бъде задушаваща точка, той трябва да се актуализира безопасно.