All the code that runs is inside SQL Server. I can assure you that there is no external application locking or mutexes involved. Any insight or help into a matter such as this would be greatly appreciated. This might have only come about since I am sending and processing several hundred messages a second and timing and latency is critical for things to move smoothly in this case. I had found that I was ending conversations using the original logic from Remus before all the other "real" messages were received off the queue. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |