So you did your polling based on a timer? and added more services if need be? how would you know if you needed to add more by the difference between locktime and Requested time?

If I am understanding your question correctly, I didn’t do any special processing. There was no multi-thread or throttling. The service(s) merely polled the queue on a given timer interval. If items were in the queue, each service would process queued items until all were processed to completion. Once all items were processed, each service would wait until the next interval fired and the polling and processing continued.

I hope this helps,
Ben

If, after the number of minutes established with @MinutesBeforeBreakLock, row processing isn’t completed, the row becomes available for processing by another thread. This logic was put in place for exactly the reason you mentioned — failures dues external issues.

Regarding your second case, that’s not built into the script right now, but it could be extended pretty easily. Off the top of my head (read: following queries should be vetted), a “NumAttempts” column could be added to the Queue table and incremented each time a given row is “pulled off” the queue as part of the update:

update Queue
set LockedBy = @LockedBy,
LockedTime = GetDate(),
NumAttempts = Coalesce(NumAttempts,0) + 1
where RequestId = @RequestId

If you want to limit the number of attempts, the select statement would be changed to something like this:

select top 1 @RequestId = RequestId
from Queue with (updlock)
where Status = @PendingStatus
and (LockedTime IS NULL OR
DateDiff(mi, LockedTime, GetDate()) >= @MinutesBeforeBreakLock)
and (NumAttempts < @AttemptsAllowed)
order by RequestedTime Asc

Note, the restriction based on NumAttempts being less than your established limit.

Thanks for the comment and the question.

what about if I need to re queue an item if processing encountered some external problem?

And what if I want to retry processing for a limited number of times, after which i drop the queue item.

Let’s say Request A and B come in at exactly the same time. Well, SQL Server will ensure that only one of the requests will get a lock on the top row – in other words, the next row to be processed in the queue.

Once a row is locked, it is no longer available and it can’t be locked by another request. It should also be noted that the lock stays in place until the associated update is performed.

If Request A gets the initial lock, Request B will lock the next row in the queue and follow the same process as Request A (lock row and capture id, update row based on LockedBy and LockedTime values, implicitly release lock.)

Did I answer your question?