Question

SQL Server 2008 R2 (Data Center edition – I think)

I have a very specific requirement for the database.

I need to insert a row marked with timestamp [ChangeTimeStamp]. Timestamp value is passed as a parameter. Timestamp has to be unique.

Two processes can insert values at the same time, and I happen to run into duplicate key insertion once in a while. To avoid this, I am trying:

declare @maxChangeStamp bigint

set transaction isolation level read committed
begin transaction 
select @maxChangeStamp = MAX(MaxChangeTimeStamp) from TSMChangeTimeStamp

if (@maxChangeStamp > @changeTimeStamp)
    set @maxChangeStamp = @maxChangeStamp + 1   
else 
    set @maxChangeStamp = @changeTimeStamp

update TSMChangeTimeStamp 
set MaxChangeTimeStamp = @maxChangeStamp 
commit

set @changeTimeStamp = @maxChangeStamp

insert statment

• REPEATABLE READ – causes deadlock
• READ COMMITTED – causes duplicate key inserts

@changeTimeStamp is my parameter.
TSMChangeTimeStamp holds only one value.

If anyone has a good idea how to solve this I will appreciate any help.

Answer 1

Inside the transaction, the SELECT statement will acquire a shared lock if the mode is not READ COMMITTED or snapshot isolation. If two processes both start the SELECT at the same time, they will both acquire a shared lock.

Later, the UPDATE statement attempts to acquire an exclusive lock (or update lock). Unfortunately, neither one can acquire an exclusive lock, because the other process has a shared lock.

Try using the WITH (UPDLOCK) table hint on the SELECT statement. From MSDN:

UPDLOCK

Specifies that update locks are to be taken and held until the
transaction completes. UPDLOCK takes update locks for read operations
only at the row-level or page-level. If UPDLOCK is combined with
TABLOCK, or a table-level lock is taken for some other reason, an
exclusive (X) lock will be taken instead.

When UPDLOCK is specified, the READCOMMITTED and READCOMMITTEDLOCK
isolation level hints are ignored. For example, if the isolation level
of the session is set to SERIALIZABLE and a query specifies (UPDLOCK,
READCOMMITTED), the READCOMMITTED hint is ignored and the transaction
is run using the SERIALIZABLE isolation level.

For example:

begin transaction
select @maxChangeStamp = MAX(MaxChangeTimeStamp) from TSMChangeTimeStamp with (updlock) 

Note that update locks may be promoted to a table lock if there is no index for your table (Microsoft KB article 179362).

Explicitly requesting an XLOCK may also work.

Also note your UPDATE statement does not have a WHERE clause. This causes the UPDATE to lock and update every record in the table (if applicable in your case).