Du beskriver i grunden ett klassiskt köbaserat arbetsflöde, och du bör överväga att använda en riktig kö .
För diskussionens skull, så här uppnår du vad du önskar:
- gör anspråk på specifik resurs:
SELECT ... FROM resources WITH (UPDLOCK, ROWLOCK) WHERE key = @key. Kommer att blockera om resursen redan har gjorts anspråk på. Använd lock timeouts för att returnera undantag om resursen redan har gjorts anspråk på.keymåste vara indexerad och unik. - nästa tillgängliga resurs:
SELECT ... FROM resources WITH (UPDLOCK, ROWLOCK, READPAST) ORDER BY <accessorder>. Du måste definiera en ordning genom att uttrycka preferensen för resurser (äldsta, högsta prioritet etc) - släpp en resurs som gjorts anspråk på:
COMMITdin transaktion.
Kärnan i problemet är att använda rätt låstips, och den här typen av problem kräver explicita låstips för att lösa. UPDLOCK kommer att fungera som ett "krav"-lås. ROWLOCK skapar rätt granularitet som hindrar servern från att "optimera" till ett sidlås. READPAST låter dig hoppa över anspråk på resurser. Att placera UPDLOCK på raderna kommer att låsa raden och låta dig uppdatera den senare, men kommer att förhindra andra operationer som vanliga läsberättigade SELECT:er som kommer att blockera på den låsta raden. Tanken är dock att du ändå ska UPPDATERA raden, vilket kommer att placera ett oundvikligt X-lås. Om du vill behålla tabellen mer tillgänglig kan du använda applås istället, men är betydligt svårare att dra av på rätt sätt. Du måste begära ett applås på en strängbeskrivning av resursen, som nyckelvärdet eller en CHECKSUM av nyckeln eller så är det %%LOCKRES%%
värde. Med applås kan du separera omfattningen av "anspråket" från en transaktion genom att begära applåset i "session"-omfattningen, men sedan måste du släppa anspråket manuellt ("transaktions"-omfattade applås släpps vid bekräftelse) . Observera dock, det finns tusen sätt att skjuta dig själv i foten med applås.