V podstatě popisujete klasický pracovní postup založený na frontě a měli byste zvážit použití skutečného fronta .
V zájmu diskuse zde je návod, jak dosáhnout toho, co si přejete:
- nárokovat konkrétní zdroj:
SELECT ... FROM resources WITH (UPDLOCK, ROWLOCK) WHERE key = @key. Zablokuje se, pokud je zdroj již nárokován. Použijte časové limity zámku k vrácení výjimky, pokud je zdroj již nárokován.keymusí být indexované a jedinečné. - další dostupný zdroj:
SELECT ... FROM resources WITH (UPDLOCK, ROWLOCK, READPAST) ORDER BY <accessorder>. Musíte definovat pořadí, které vyjadřuje preferenci zdrojů (nejstarší, nejvyšší priorita atd.) - uvolněte nárokovaný zdroj:
COMMITvaší transakci.
Podstatou problému je použití správných tipů na zamykání a tento druh problému vyžaduje k vyřešení explicitní tipy na zamykání. UPDLOCK bude fungovat jako „nárokovací“ zámek. ROWLOCK vytváří správnou granularitu, která brání serveru v „optimalizaci“ na zámek stránky. READPAST umožňuje přeskočit nárokované zdroje. Umístěním UPDLOCK na řádky se řádek uzamkne a umožní vám jej později aktualizovat, ale zabrání dalším operacím, jako jsou běžné SELECTy s potvrzením čtení, které se na uzamčeném řádku zablokují. Myšlenka je však taková, že stejně budete řádek AKTUALIZOVAT, což vytvoří nevyhnutelný zámek X. Pokud chcete, aby byla tabulka dostupnější, můžete použít zámky aplikací místo toho, ale je podstatně obtížnější správně vytáhnout. Budete muset požádat o zámek aplikace na popisovači řetězce zdroje, jako je hodnota klíče nebo CHECKSUM klíče nebo je to %%LOCKRES%%
hodnota. Zámky aplikace vám umožňují oddělit rozsah „nároku“ od transakce tím, že požádáte o zámek aplikace v rozsahu „relace“, ale pak musíte nárok uvolnit ručně (zámky aplikace s rozsahem „transakce“ jsou uvolněny v okamžiku potvrzení) . Pozor, existuje tisíc způsobů, jak se střelit do nohy pomocí zámků aplikací.