April 8, 2010 at 3:28 pm
Ahmad Alkilani (4/5/2010)
The solution simply illustrates in general what you can do to get around the problem. You can most certainly add ordering, user audits and resolutions to orphaned items. Then again, if you have a necessity to solve these issues in your application you might want to consider going with SQL Server Service Broker 🙂
And if you were going to consider that, it might be a good idea to read http://rusanu.com/2010/03/09/dealing-with-large-queues/ first, as well as worrying about using a message passing interface as your interface to your queus and the need to have a few auxiliary tables since you can't affect or adjust in any way the structure of the tables underlying SQL Service Broker "Queues".
Also, if you have a high queue insertion rate (as you will for example if you are handling the request queue in a discrete event simulator, or in most simulation-based prediction generators) you are going to have to have a housekeeping task to do index reorganisation pretty frequently whether you use Service Broker Queues or roll your own and that is much easier to do if you roll your own.
Tom
April 8, 2010 at 3:40 pm
tony.turner (4/6/2010)
In my view the code fragment from Ahmad is missing a number of considerations that should be taken into account for a practical SQL table-based queueing systems:
I agree that much is missing, but not with the idea that Service Broker is a good approach for high queue throughput (see previous comment) or with the idea that nontransactional access (it issn't clear whether you actually mean separate transactions in a paralell session or something else) to status is a good approach to defensive programming here.
So, in summary. Simple, yes. Realistic, not close
Yes, that was my feeling too.
Tom
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply