Autonumbering causing deadlocks.

Gents,

I have come into a system that uses a secondary table to generate (for
want of a better word) Identities.

eg

create table myidents
( name sysname not null, ident int not null)

create procedure getnextident @.table sysname, @.ident int output
as
begin
if not exists (select top 1 1 from myidents where name = @.table)
insert into myidents values (@.table, 0)

update myidents
set @.ident = ident = ident + 1
where name = @.table
end

now, (ignoring for now the use of reserved words) the problem is that
this is called frequently, from other procedures. Trouble is that the
calling procedures call it from within a transaction. We now have a
wickedly hot spot on this table, with frequent deadlocks.

Is there any relatively quick fix for this? Some locking hints or
whatever.

Or do we need to go and recode, moving this kind of thing outside the
transaction (which are all rather too long for my liking), and even
cosidering using identity columns as a replacement?

ThanksIMHO, IDENTITY would be the best approach with the current design. You
might also consider using natural keys instead of surrogate key values.

If your actual myident table has no primary key on name, this will
contribute to blocking/deadlocking. Unless your application always acquires
values in the same sequence, you will be vulnerable to deadlocks unless you
specify a TABLOCKX hint. This is obviously bad for concurrency (especially
for long-running transactions) and should be avoided if possible.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"WangKhar" <Wangkhar@.yahoo.com> wrote in message
news:bb269444.0401220321.38788fa2@.posting.google.c om...
> Gents,
> I have come into a system that uses a secondary table to generate (for
> want of a better word) Identities.
> eg
> create table myidents
> ( name sysname not null, ident int not null)
> create procedure getnextident @.table sysname, @.ident int output
> as
> begin
> if not exists (select top 1 1 from myidents where name = @.table)
> insert into myidents values (@.table, 0)
> update myidents
> set @.ident = ident = ident + 1
> where name = @.table
> end
> now, (ignoring for now the use of reserved words) the problem is that
> this is called frequently, from other procedures. Trouble is that the
> calling procedures call it from within a transaction. We now have a
> wickedly hot spot on this table, with frequent deadlocks.
> Is there any relatively quick fix for this? Some locking hints or
> whatever.
> Or do we need to go and recode, moving this kind of thing outside the
> transaction (which are all rather too long for my liking), and even
> cosidering using identity columns as a replacement?
> Thanks|||You could try this:

if not exists (select top 1 1 from myidents ROWLOCK, UPDLOCK where name =
@.table)

Hope it will help.

Igor

"WangKhar" <Wangkhar@.yahoo.com> wrote in message
news:bb269444.0401220321.38788fa2@.posting.google.c om...
> Gents,
> I have come into a system that uses a secondary table to generate (for
> want of a better word) Identities.
> eg
> create table myidents
> ( name sysname not null, ident int not null)
> create procedure getnextident @.table sysname, @.ident int output
> as
> begin
> if not exists (select top 1 1 from myidents where name = @.table)
> insert into myidents values (@.table, 0)
> update myidents
> set @.ident = ident = ident + 1
> where name = @.table
> end
> now, (ignoring for now the use of reserved words) the problem is that
> this is called frequently, from other procedures. Trouble is that the
> calling procedures call it from within a transaction. We now have a
> wickedly hot spot on this table, with frequent deadlocks.
> Is there any relatively quick fix for this? Some locking hints or
> whatever.
> Or do we need to go and recode, moving this kind of thing outside the
> transaction (which are all rather too long for my liking), and even
> cosidering using identity columns as a replacement?
> Thanks|||WangKhar (Wangkhar@.yahoo.com) writes:
> create procedure getnextident @.table sysname, @.ident int output
> as
> begin
> if not exists (select top 1 1 from myidents where name = @.table)
> insert into myidents values (@.table, 0)
> update myidents
> set @.ident = ident = ident + 1
> where name = @.table
> end
> now, (ignoring for now the use of reserved words) the problem is that
> this is called frequently, from other procedures. Trouble is that the
> calling procedures call it from within a transaction. We now have a
> wickedly hot spot on this table, with frequent deadlocks.
> Is there any relatively quick fix for this? Some locking hints or
> whatever.

Deadlocks can usually be avoided by:

BEGIN TRANSACTION

SELECT @.ident = ident FROM tbl (UPDLOCK) WHERE name = @.table
UPDATE tbl SET ident = @.ident WHERE name = @.table

COMMIT TRANSACTION

However, if you have more work in the transaction, you will have lot of
blocking and not much concurrency in the system. And if you in some
procedures perform work before you come here, they might be blocking
other processes that aleady have an ident, and now wil block the other
prcoess.

The above is only really meaningful if you have busienss rules that
require consecutive series. Else you should move out the ident-generation
out of the transaction or use IDENTITY instead.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Thanks thats pretty much what I thought ...

See if I can convince people that we need to take this action :(

Erland Sommarskog <sommar@.algonet.se> wrote in message news:<Xns94794AA4B719Yazorman@.127.0.0.1>...
> WangKhar (Wangkhar@.yahoo.com) writes:
> > create procedure getnextident @.table sysname, @.ident int output
> > as
> > begin
> > if not exists (select top 1 1 from myidents where name = @.table)
> > insert into myidents values (@.table, 0)
> > update myidents
> > set @.ident = ident = ident + 1
> > where name = @.table
> > end
> > now, (ignoring for now the use of reserved words) the problem is that
> > this is called frequently, from other procedures. Trouble is that the
> > calling procedures call it from within a transaction. We now have a
> > wickedly hot spot on this table, with frequent deadlocks.
> > Is there any relatively quick fix for this? Some locking hints or
> > whatever.
> Deadlocks can usually be avoided by:
> BEGIN TRANSACTION
> SELECT @.ident = ident FROM tbl (UPDLOCK) WHERE name = @.table
> UPDATE tbl SET ident = @.ident WHERE name = @.table
> COMMIT TRANSACTION
> However, if you have more work in the transaction, you will have lot of
> blocking and not much concurrency in the system. And if you in some
> procedures perform work before you come here, they might be blocking
> other processes that aleady have an ident, and now wil block the other
> prcoess.
> The above is only really meaningful if you have busienss rules that
> require consecutive series. Else you should move out the ident-generation
> out of the transaction or use IDENTITY instead.