Update / Select and readpast locks

Question

Hi everybody,
We are running into concurrency issue with one of the applications that uses multi threading (200 threads / sec running that query (in a stored procedure)). The query with the concurrency issue is the following one:
--retrieve the oldest record that needs to be processed
select top 1 @conversation_id = conversation_id from
conversation with (rowlock) , network_carrier
with (rowlock)
where
conversation.[to] = network_carrier.full_carrier_oid and
network_code = @network_code and
process = 'R' and
process_count < 3
order by conversation_id asc
--update that record to 'processing' if it has not been grabbed by someone else since we selected it above
update conversation with (rowlock)
set process = 'S',
process_time = getdate(),
process_count = process_count +1
where
conversation_id = @conversation_id and
process = 'R'
--if the rowcount is > 0, that means we got it, so return it
if @@ROWCOUNT > 0
select * from conversation with (rowlock) where conversation_id = @conversation_id
So, in order to fix this, since we cannot change the application at this time, I was thinking of changing completely the way the query works to the following:
declare @conversation_id int
--update that record to 'processing' if it has not been grabbed by someone else since we selected it above
update conversation with (rowlock)
set process = 'S',
process_time = getdate(),
process_count = process_count +1,
@conversation_id = conversation_id
where
conversation_id = (
select top 1 conversation_id from
conversation with (readpast) , network_carrier
with (rowlock)
where
conversation.[to] = network_carrier.full_carrier_oid and
network_code = @network_code and
process = 'R' and
process_count < 3
order by conversation_id asc
select * from conversation with (rowlock) where conversation_id = @conversation_id
But even though the documentation says:
* A queue reader that uses READPAST skips past queue entries locked by other transactions to the next available queue entry, without having to wait until the other transactions release their locks.
* When specified in an UPDATE statement, READPAST is applied only when reading data to identify which records to update, regardless of where in the statement it is specified
Does this skipping include SHARED LOCKS made by selects ?
Thanks

Answer 1

Assuming that this is inside a transaction, I would change the SELECT to:
SELECT TOP (1) @conversation_id = c.conversation_id
FROM   conversation c WITH (UPDLOCK, READPAST)
WHERE  EXISTS (SELECT *
               FROM   network_carrier nc
               WHERE  c.[to] = nc.full_carrier_oid
                 AND  nc.network_code = @network_code)
 AND     c.process = 'R'
 AND   c.process_count < 3
ORDER  BY c.conversation_id ASC
I had to make a complete guess in which tables the unprefixed columns are, so you may need to rearranged.
I rewrote it with EXISTS, since that is apparently the purpose of the query.
I took out the ROWLOCK, because I don't see the point with them - if SQL Server feel compelled to escalate to table locks, you have bigger problems.
As for the locking, you need UPDLOCK to reserve a row, so that multiple process cannot grab the same guy. UPDLOCK is a shared lock that only can be held by one process. That is, regaular SELECT is still possible, but no one else can take an UPDLOCK, so they
will be blocked. Or would have, if it had not been for the READPAST hint.
I prefer to have the queries separate, as it makes clear what is happening. If you use an UPDATE with a subquery, the result may not be the expected.
Erland Sommarskog, SQL Server MVP, [email protected]