July 31, 2009 at 8:45 am
Hi,
I'm a little bit curious to know what's going to happen when we dont end the conversation on the Initiator side after receiving the response message from the target side.
I know that the message will be sitting in the initiator queue and the STATE for that conversation in the sys.conversation_endpoints view would be 'DI'. Is that going to hurt my further process if I dont receive the message from the Initiator queue and end the conversation?
Can someone explain me in detail.
Thanks in advance
July 31, 2009 at 10:53 am
It just leaves the conversation open, which in theory can be used by other senders (if they know the conversation handle).
The only bad things, AFAIK is that if you are not leaving them opento reuse them, but rather keep opening new conversations and leave them open also, then the Service Broker support tables will begin to fill up with open but unused conversations.
Eventually this could get big enough to affect the performance of Service Broker functions, so I would suggest either having the initiators close them appropiately, OR have the responder close them (I think that this works...), OR re-use them, OR periodically clean them out (making sure not to kill any that should be reused).
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
July 31, 2009 at 12:23 pm
Barry thanks for your reply.
If the target ends the conversation and it doesn't send any response message then what would happen to the conversation?
on the initiator side will the conversation be in open or closed status ?
July 31, 2009 at 5:55 pm
I think that it gets closed when the Target closes it, but I am not sure. Why not just test it and let us know?
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
July 31, 2009 at 8:57 pm
Heh... I had to look... The title of this thread reminded me of my first wife. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
July 31, 2009 at 9:59 pm
Hey,
Do u have any idea of my question?
August 1, 2009 at 12:06 am
Nah... sorry. Just passing through. I don't even know how to spell "Service Broker".
--Jeff Moden
Change is inevitable... Change for the better is not.
August 1, 2009 at 12:59 pm
sql server developer (7/31/2009)
Hey,Do u have any idea of my question?
Have you tried what I suggested yet?
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
June 23, 2010 at 4:32 pm
Both the target and the initiator have to call "end conversation @handle;" on each conversation. When either end does the 1st 'end conversation' that will make service broker deliver an 'EndDialog'-message to the service at the other end of the conversation. This has to respond to this message by at least calling "end conversation @handle;". If you don't pick up that message you'll have one remaining message sitting in your queue after you're done processing your functional messages. Only after both ends have confirmed the conversation has ended, service broker can go ahead and clean out the conversation.
Remus Rusano has written lots of information on how to use service broker: http://rusanu.com/articles/
June 24, 2010 at 9:57 pm
Sorry Barry, I haven't tested it yet. Its been a while since i've worked on it. I'll definitely test it and let you know.
Thanks!
June 28, 2010 at 1:45 am
sql server developer (6/24/2010)
Sorry Barry, I haven't tested it yet. Its been a while since i've worked on it. I'll definitely test it and let you know.Thanks!
We end all of our conversations on the intiator side. Then a message is sent to the receiver side.
Our receive procs all look like this:
RECEIVE TOP(1)
@RecvHandle = conversation_handle,
@TmpMessage = message_body,
@RecvReqMsgName = message_type_name
FROM ProcessQueue
IF @RecvReqMsgName = N'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
BEGIN
END CONVERSATION @RecvHandle
END ELSE
BEGIN
-- Process your message here
END
I would imagine that if you end the conversation on the receiver side then that same message will be generated and sent in reverse.
You would then have to receive on your initiator queue and close the conversations that have that message come in. I have not tested it that way around though - please post your results here 🙂
June 28, 2010 at 7:00 am
I hope you're not ending the conversations at the initiator side right after you've sent your message(s). If so, do yourself a favor and read Remus' explanation why you should never do that, plus some solutions to avoid this pitfall: http://rusanu.com/2006/04/06/fire-and-forget-good-for-the-military-but-not-for-service-broker-conversations/.
June 28, 2010 at 10:20 am
Hi R.P.
We have a web app as our front end, and start one conversation per user session per queue that we use.
These conversations are kept, and when the back-end app is completely done with the session, a special message is sent that tells us to close all of our conversations.
So, to answer your question: No we do not 🙂
Another consideration for our app is that all queuing lives on a single database instance, it is not cross-instance. So the pitfall that is mentioned in that article will not apply to us.
I do have a separate queuing route that sends messages to the queing database, but that only uses a single conversation, which is never closed.
That is an interesting link though, I might look into closing our conversations the other way around when we do close them.
Regards,
Joon
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply