Dette er to kommentarer, der indsættes med samme content_id. Blot at indsætte kommentaren vil fjerne en DEL-lås på indholdsrækken, for at stoppe en anden transaktion, der sletter den række, indtil den første transaktion er gennemført.
Udløseren fortsætter dog derefter med at opgradere låsen til EXCLUSIVE, og dette kan blokeres af en samtidig transaktion, der udfører den samme proces. Overvej følgende begivenhedsforløb:
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)
Så- dødvande.
En løsning er at med det samme tag en eksklusiv lås på indholdsrækken før indsætte kommentaren. dvs.
SELECT 1 FROM content WHERE content.id = 935967 FOR UPDATE
INSERT INTO comment(.....)
En anden løsning er ganske enkelt at undgå dette "cached counts"-mønster helt, undtagen hvor du kan bevise, at det er nødvendigt for ydeevnen. Hvis det er tilfældet, så overvej at opbevare det cachelagrede antal et andet sted end indholdstabellen - f.eks. et dedikeret bord til disken. Det vil også skære ned på opdateringstrafikken til indholdstabellen, hver gang en kommentar tilføjes. Eller måske bare genvælge antallet og bruge memcached i applikationen. Der er ingen udenom det faktum, at uanset hvor du gemmer dette cachelagrede antal vil være et chokepunkt, skal det opdateres sikkert.