This basically assures me that a conversation is really over after about 20 minutes of idle time and I won't get DialogTimer/EndOfStream messages all mixed in with other "real" messages. What I've done to work around this is threefold: I've reduced the scope of my transactions to be as small as possible with the side effect of possibly losing data due to rollbacks (some of my SENDs and RECEIVEs are no longer part of the transactions so there is potential for data loss), I've changed the locking behavior on my initiator procedure to use XLOCK and ROWLOCK hints on SessionConversations (which has helped), and I've changed the conversation timer logic to constantly push the timeout further out each time a message is sent. During this time, SQL Server doesn't appear to take any corrective measures to end the deadlock. Calls to the Send process can still happen but they will all wait and be blocked. They all have resources locked that each other needs and it's a classic deadlock issue between multiple processes. What I end up with is Process A waiting on Process B waiting on Process C waiting on Process A. I have done this with and without any type of locking hint with the same results. Process C (the initiator activation procedure) is trying to read from the initiator queue and process DialogTimer and EndDialog messages as well as select/delete rows from SessionConversations during its transaction.Process B (the target activation procedure) is trying to read from the target queue and also process EndOfStream messages which send to the initiator queue locking the conversation there as well during its transaction. #Three way deadlock updateProcess A (the Send procedure) takes out update locks (via UPDLOCK hint) on the SessionConversations table and also while sending on the conversation locks the target queue for that conversation or conversation group (the same in this case) during its transaction.What I think is happening is the following: It appears from all the information I can see is that a multi-process deadlock has occured and it doesn't look like SQL Server can handle it properly. What I end up with occasionaly is a situation where everything (message submittal, activation processing, etc.) comes to a grinding halt. I process at most about 20-30 messages at a time and I only submit one message per Send procedure call.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |