Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Implementing Queuing Mechanism Expand / Collapse
Author
Message
Posted Tuesday, July 12, 2011 1:42 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, November 13, 2014 7:04 AM
Points: 9, Visits: 436
Comments posted to this topic are about the item Implementing Queuing Mechanism
Post #1140162
Posted Tuesday, July 12, 2011 3:59 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, January 17, 2014 6:38 AM
Points: 278, Visits: 534
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)
V1 238
NULL 32275
v2 255

Post #1140195
Posted Tuesday, July 12, 2011 4:03 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, January 17, 2014 6:38 AM
Points: 278, Visits: 534
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 (??!)
Post #1140198
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse