none
Do all conversations have to be bi-directional?

    Question

  • From a service broker newbie...

     

    Most of the examples I've found and played with demonstrate two way conversation.  A sender initiates a call, and gets a message back. 

     

    My Requirements doesn't really need two way communication.  I have a scenario where triggers on two different tables result in modifications to a third table, and I don't want the triggers to deadlock each other, so an asynchronous queueing mechanism seems like the perfect solution...  

     

    But I can't seem to make it work one way. 

     

    I can get one message through, and then all subsequent messages hang up in the transmission queue with the very informative "One or more messages could not be delivered to the local service targeted by this dialog."

     

    I'm thinking all the examples work the way they do because you have to notify the transmitter that the message was

    received by sending a message back... and by not doing this I'm stuck in the first conversation.  I was thinking that by doing END CONVERSATION <Msg Handle> in the stored procedure bound to the receiver's queue was doing that.

     

    Do I have to communicate bi-directionally always?  I guess this is a safety feature but I trust MSMQ to deliver messages...

     

    Thx

     

     

    Thursday, March 20, 2008 9:49 PM

Answers

  • The one-directionality or bi-directionality of the conversations has probably nothing to do with your undeliverable messages. Most likely your activated procedure has a problem and rolls back, thus disabling the target queue. Best way to troubleshoot is to attach the SQL PRofiler and monitor the SSB events. Perhaps you can also download the SQL 2008 CTP6 and use the included ssbdiagnose tool in /RUNTIME mode, it can connect and diagnose problems on SQL 2005 instances.

     

    As for the question whether you should do one-directional (ie. SEND followed by END CONVERSATION from the initiator, probably in the same procedure) or bi-directional (SEND and target responds with END CONVERSATION) you are right, the one-directional pattern is tempting, but there are a few differences from the MSMQ scenario. That is because the SSB 'stream' (conversation) semantics cannot work with a 'dead letter queue', so errors (including delivery failures) have to be returned to the sender's queue (they have to be put in the 'stream', ie. the conversation). This was a deliberate decision made during SSB development, that an application should monitor one and only one place: the service queue. Having to look in two places for each busines transaction (service queue and 'dead letter queue') makes a horrible programming model and is very prone to bugs and race conditions.

    So while technically you can use one-directional pattern, you are effectively giving up any form of delivery error feedback. this is the first and foremost reason why I insist so much not to use it. The second reason is that there is still an issue with the SSB internals that expose a delivery bug in this scenario (target conversation endpoints are not deleted), see http://rusanu.com/2007/08/21/service-broker-leaked-target-conversation-endpoints-fix-ships-in-cumulative-update-for-sql-server-2005-sp2/

     

    And finally the true 'one-directional' conversations in SSB (so called monologs or publish-subscribe) are still in the books for a future release.

     

    Friday, March 21, 2008 8:24 AM
    Moderator

All replies

  • The one-directionality or bi-directionality of the conversations has probably nothing to do with your undeliverable messages. Most likely your activated procedure has a problem and rolls back, thus disabling the target queue. Best way to troubleshoot is to attach the SQL PRofiler and monitor the SSB events. Perhaps you can also download the SQL 2008 CTP6 and use the included ssbdiagnose tool in /RUNTIME mode, it can connect and diagnose problems on SQL 2005 instances.

     

    As for the question whether you should do one-directional (ie. SEND followed by END CONVERSATION from the initiator, probably in the same procedure) or bi-directional (SEND and target responds with END CONVERSATION) you are right, the one-directional pattern is tempting, but there are a few differences from the MSMQ scenario. That is because the SSB 'stream' (conversation) semantics cannot work with a 'dead letter queue', so errors (including delivery failures) have to be returned to the sender's queue (they have to be put in the 'stream', ie. the conversation). This was a deliberate decision made during SSB development, that an application should monitor one and only one place: the service queue. Having to look in two places for each busines transaction (service queue and 'dead letter queue') makes a horrible programming model and is very prone to bugs and race conditions.

    So while technically you can use one-directional pattern, you are effectively giving up any form of delivery error feedback. this is the first and foremost reason why I insist so much not to use it. The second reason is that there is still an issue with the SSB internals that expose a delivery bug in this scenario (target conversation endpoints are not deleted), see http://rusanu.com/2007/08/21/service-broker-leaked-target-conversation-endpoints-fix-ships-in-cumulative-update-for-sql-server-2005-sp2/

     

    And finally the true 'one-directional' conversations in SSB (so called monologs or publish-subscribe) are still in the books for a future release.

     

    Friday, March 21, 2008 8:24 AM
    Moderator
  • Thanks that really helps.

     

    Friday, March 21, 2008 1:14 PM