Fake update or select with (udplock) or select with (updlock, rowlock)?

Question

I need  to block some rows to control the concurrency. I have this table:
Table(ID, Concurrency...)
Concurrency is a nullable bit that is only used to do the fake update.
I need to block the row to avoid that the row is selected by a second process one the first select it. So by the moment I am doing:
begin tran
Update Table set Concurrency = Concurrency where ID = 123
--My process
commit
In this case, when two process execute the same code, the first one block the row with ID 123 and the second process has to wait until the first process ends.
I am trying to use hints for this, to avoid the need of the fake update, because I guess that has worst performance than a select, so I have tried something like that:
begin tran
select * from Table with(rowlock, xlock) where ID = 123
commit
With serializable isolation level too, that is the most restrictive, but sometimes, with some conditions in the where, the row is not blocked. So that is the reason why I am using the fake update, because the update works always.
However, I have read that I can use the hint UPDLOCK, that seems that locks the row in the select, but how it is a hint, I am not sure if this solution block always the row or sometimes doesn't do it, like the rowlock, xlock. I have tested this and it seems
that works, but when I use an ID as condition, I don't know if it works in all cases.
Another alternative that I have seen is with (UPDLOCK, ROWLOCK). What is the difference? Because with only UPDLOCK only locks the rows affected by the conditions in the where, so I am not sure why to use ROWLOCK too.
What I want is to ensure that I block the row until the process has finished.
There are any other alternative to block a row to avoid the select?
Thank so much.

Answer 1

First of all, have you looked at application locks? Maybe this is what's need rather than fake updates?
UPDLOCK is a hint on the same parity as XLOCK. XLOCK takes out an exclusive lock, and no other process can access the row. But some the engine dodges the lock it seems.
UPDLOCK does not prevent other process from reading the row with a regular shared lock. However, only one process at a time can have an Update lock on a row. The purpose for an UPDLOCK is to mark that you intended to update the row later.
ROWLOCK controls the granuality, and since row lock is the default lock granularity it should not be needed in very many cases.
Erland Sommarskog, SQL Server MVP, [email protected]