November 26, 2007 at 2:44 pm
you should add UPDLOCK hint to the "select" statement on the batch...
Cheers,
* Noel
November 26, 2007 at 2:59 pm
thanks, that should help prevent deadlocking which was one concern, but I don't think it will stop the second call of the same stored procedure from reading the same rows.
I do thank you for telling me about the UPDLOCK hint...I'm still kind of new, and I see how valuable this is.
November 26, 2007 at 3:08 pm
Ok, I got it, I need UPDLOCK and READPAST hints together. As explained here
So my statement should read.
WITH Requests AS
(
Select Top(3) *
FROM ReportRequest_R2 WITH (UPDLOCK, READPAST)
WHERE Status = 'O'
ORDER BY RequestDate ASC
)
UPDATE Requests
SET
Status = 'P',
StatusDate = getdate(),
StatusDesc = 'Processing',
LockGUID = @GUID,
ProcessCount = ProcessCount + 1
WHERE RowNum <= 3
November 27, 2007 at 4:46 am
And wrap it all in a transaction.
Also, make sure you include the old data values in the update statement. That way, if the second call manages to get the same three rows, but has to wait for the first transaction to commit, when it goes to update, if the data doesn't match, no rows will be affected.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 4 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply