Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
All examples I find on the web for using SQL Server Service Broker queues seem to have two queues. I don’t understand why and every example seems to assume that this is so obvious as to be unnecessary to explain.
Several things will write to my queue and a stored procedure will read from it and insert to database. Why do I need two queues?
For example: http://www.techrepublic.com/article/use-service-broker-internal-activation-in-sql-server-2005/6156264#
Technically you can use one queue using SSB technology in your application. In this case this queue has a mess from request messages from initiator and response messages from target. Your stored procedure should implement mechanism to distinguish one from another, sort out them, decide which response is for which request and so on. Also take in mind that RECEIVE messages from this queue in exact order and you can’t skip some of them and leave in queue for further processing.
Maybe better in your case to follow Remus Rusanu’s answer and implement your queue using database table?
SSB idea is simple – Initiator places request message into Target’s queue while waiting response message from Target in its own queue. Is it your case? If no, maybe you need not SSB at all?