Zoals verwacht
-
De SELECT met ORDER BY, zonder ROWLOCK, zonder index zal een table lock hebben vanwege een scan/tussensortering om TOP 2 uit te werken. Dus de 2e sessie slaat de hele tabel over vanwege READPAST
-
De SELECT zonder de ORDER BY kiest gewoon 2 rijen, die toevallig in de volgorde van invoegen staan (puur toeval, er is geen impliciete volgorde). Het feit dat deze 2 rijen zijn vergrendeld, zorgt ervoor dat de 2e sessie naar de volgende niet-vergrendelde rijen gaat.
SQL Server probeert vergrendelingen zo gedetailleerd mogelijk te houden, maar de scan betekent een tabelvergrendeling. Dit zou normaal gesproken geen verschil maken (het zou een gedeelde leesvergrendeling zijn), maar je hebt ook UPDLOCK, wat een exclusief vergrendelde tabel betekent
Dus je hebt deze beide nodig
- 3 hints in de SELECT-query's (ROWLOCK, UPDLOCK, READPAST) om granulariteit, isolatie en gelijktijdigheid te controleren.
Als u alleen ROWLOCK gebruikt, krijgt u nog steeds een exclusieve vergrendeling op elke rij om te scannen/sorteren. - een index op
ValueINCLUSIEFTestIDom de SELECT efficiënt te maken. Alleen een index zal waarschijnlijk de gelijktijdigheid oplossen, maar het zal niet worden gegarandeerd.
In een van je eerdere vragen heb ik gelinkt naar mijn antwoord (in een reactie) op SQL Server Process Queue Race Conditie waar ik alle 3 slothints heb