none
begin conversation timer (@h) timeout =..

    Question

  • From examples I found concerning begin conversation timer and tried by myself I concluded the following:

    1. In the code which initiate the conversation - it will define the time of delay till the conversation begins.
    2. In the asynchronous procedure activated by the queue - it causes it to be executed in a loop, and define the time between the iterations.

    Am I right?
    Is there a way to count the iterations and to know (inside the procedure) how many time it has been activated?



    Thursday, April 10, 2014 2:10 PM

Answers


    1. In the code which initiate the conversation - it will define the time of delay till the conversation begins.

    No, BEGIN CONVERSATION TIMER defines the delay until a DialogTimer message is sent to the other side of an existing conversation.  One use case for a DialogTimer is to signal to the other side of the conversation that the application is no longer active.  For example, the initiator might execute BEGIN CONVERSATION TIMER every 30 seconds, with a 60 second timeout.  This will cause a DialogTimer message to be sent to the target 30-60 seconds after the initiator service application is shut down so that the target can perform any related actions.  This is the example used in the related Books Online topic:  http://technet.microsoft.com/en-us/library/ms187804.aspx

    2. In the asynchronous procedure activated by the queue - it causes it to be executed in a loop, and define the time between the iterations.

    A DialogTimer message can be used to trigger an activated proc since any message will trigger activation.  It would normally be the initiator service that starts the timer but you could have the target service start the timer at the completion of its processing, acting in the role of the initiator service.

      Is there a way to count the iterations and to know (inside the procedure) how many time it has been activated?

    Sure, just create a table that is updated by the activated proc every time it is activated.  Alternatively, you could insert a new row into a history table and count the rows for any given time interval.


    Dan Guzman, SQL Server MVP, http://www.dbdelta.com

    Monday, April 14, 2014 12:47 PM
  • No, BEGIN CONVERSATION TIMER defines the delay until a DialogTimer message is sent to the other side of an existing conversation. 

    Actually no. The DialogTimer message is not sent to the other side. It puts a message on the local queue for the conversation.

    Tuesday, April 15, 2014 12:12 PM

All replies

  • Hello,

    Thank you for your question. I am trying to involve someone more familiar with this topic for a further look at this issue. Sometime delay might be expected from the job transferring. Your patience is greatly appreciated. 

    Thank you for your understanding and support.

    If you have any feedback on our support, please click here.

    Regards,


    Elvis Long
    TechNet Community Support

    Monday, April 14, 2014 10:01 AM

    1. In the code which initiate the conversation - it will define the time of delay till the conversation begins.

    No, BEGIN CONVERSATION TIMER defines the delay until a DialogTimer message is sent to the other side of an existing conversation.  One use case for a DialogTimer is to signal to the other side of the conversation that the application is no longer active.  For example, the initiator might execute BEGIN CONVERSATION TIMER every 30 seconds, with a 60 second timeout.  This will cause a DialogTimer message to be sent to the target 30-60 seconds after the initiator service application is shut down so that the target can perform any related actions.  This is the example used in the related Books Online topic:  http://technet.microsoft.com/en-us/library/ms187804.aspx

    2. In the asynchronous procedure activated by the queue - it causes it to be executed in a loop, and define the time between the iterations.

    A DialogTimer message can be used to trigger an activated proc since any message will trigger activation.  It would normally be the initiator service that starts the timer but you could have the target service start the timer at the completion of its processing, acting in the role of the initiator service.

      Is there a way to count the iterations and to know (inside the procedure) how many time it has been activated?

    Sure, just create a table that is updated by the activated proc every time it is activated.  Alternatively, you could insert a new row into a history table and count the rows for any given time interval.


    Dan Guzman, SQL Server MVP, http://www.dbdelta.com

    Monday, April 14, 2014 12:47 PM
  • No, BEGIN CONVERSATION TIMER defines the delay until a DialogTimer message is sent to the other side of an existing conversation. 

    Actually no. The DialogTimer message is not sent to the other side. It puts a message on the local queue for the conversation.

    Tuesday, April 15, 2014 12:12 PM
  • Thanks all for your answers and help!
    My conclusions are:

    1. In the code which initiate the conversation, the "begin conversation timer" defines how long the system will wait after the beginning of the conversation till the message will be sent to the queue.
    2. In the initiated procedure, the "begin conversation timer" will cause it to send a new message to the queue (after the timeout expires), and that would initiate the procedure again.
    3. There is no built in counter which counts how many times each procedure was initiated in each conversation, and thus we should create our own solution using a dedicated table.

    Thanks again!



    Tuesday, April 15, 2014 5:32 PM
  • Actually no. The DialogTimer message is not sent to the other side. It puts a message on the local queue for the conversation.

    You are of course correct.  I have an existing application that uses the heartbeat pattern I mentioned.  I overlooked that it was using the conversation handle from the other side of the conversation for the keep alive timer.  Thanks for the correction.


    Dan Guzman, SQL Server MVP, http://www.dbdelta.com

    Wednesday, April 16, 2014 11:09 AM