What is actually happening when a conversation timer is being used in terms of the dialog_timer column in sys.conversationendpoints? For example, I was using the following query to tell me which conversation timers are currently running:
SELECT * FROM sys.conversation_endpoints
WHERE dialog_timer > '1900-01-01 00:00:00.000'
However, I have noticed that periodically the dialog_timer value goes back to '1900-01-01 00:00:00.000' and the query fails, starting up another timer. Then, the original timer magically appears again, working just fine. So, I changed to this query:
SELECT * FROM sys.conversation_endpoints
WHERE far_service
IN
(
'TimerService1',
'TimerService2',
'TimerService3',
)
But this seems like the long way around and doesn't really indicate that the timer is running or not, just that its present in the sys.conversationendpoints catalog view. What is the proper way to see if timers are running? If one dies for some reason, I need to restart it.
What is going on with this? The timers keep getting set back to'1900-01-01 00:00:00.000' and the jobs don't get executed. What does this mean? How to correct it - its seems that the conversation_handle is still there and fine, but the timer isn't working.
|||The dialog_timer is set whenever the BEGIN CONVERSATION TIMER is executed. It's value is the time (UTC) at which the timer should 'fire' (send the Timer message). The dialog_timer is reset back to '1900-01-01 00:00:00.000' whenever the timer message is enqueued into the service queue. If you see the dialog_timer value reset, it means the timer has fired and a timer message is waiting in the service queue.
