July 12, 2011 at 1:42 am
Comments posted to this topic are about the item Implementing Queuing Mechanism
July 12, 2011 at 3:59 am
That logic can be done in one single update (which doesn't require any particular locking strategies or isolation levels):
DECLARE @nextMergeID INT ;
DECLARE @customerID INT;
DECLARE @mergeDate DATETIME;
DECLARE @reset BIT;
UPDATE dbo.merge_standard_queue
SET @nextMergeID = merge_id
, picked = 1
, lub = 'v2'
WHERE merge_id = (
select top 1 merge_id
from dbo.merge_standard_queue
where picked = 0
order by merge_date asc
);
GO 255
testing your method against the above single update, I created a merge_standard_queue table:
drop table dbo.merge_Standard_Queue
GO
create table dbo.merge_standard_queue
( merge_id int identity(1,1) not null primary key
, merge_date date not null
, picked bit not null
, lub varchar(10) null
)
GO
INSERT INTO dbo.merge_Standard_Queue (picked, merge_Date)
select 0
, DateAdd(day,t.Number, '2010-01-01')
from tally t
GO
(my tally table has 32,767 rows, so that's a reasonable size to test against).
Then I opened two separate windows in SSMS, one with your script (amended to set lub to 'v1'), and one with the single update version above, and ran them both 255 times concurrently (with a GO 255).
The results were interesting...
Both reported "Batch execution completed 255 times.", but your script never updated 255 rows, whereas the single update statement always updated 255 rows every time.
select lub, count(*) from dbo.merge_standard_Queue group by lub
returned (as an example, the actual number of updated rows varied between iterations)
lub(No column name)
V1238
NULL32275
v2255
July 12, 2011 at 4:03 am
Trying the test again, but with 2 windows both running your original script concurrently, then both updated 255 rows every time.
I can't explain this, but it must be something to do with the locking (??!)
May 12, 2016 at 7:29 am
Thanks for another good script Harsha.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply