I am troubleshooting a deadlock issue that occurred earlier. When examining the SQL trace log, I notice that at the exact time the problem starts all excessive queries have a connection type of 'CLIENT EXTRA - read-only'.
Never before was this connection type logged and I can't find any documentation on it. My best guess is that these are stored procedure calls (all related to number sequences), and that they never showed before because they don't normally pass the performance trhreshold. However, I'd like to eliminate the guesswork, so I was curious if anybody can shed some light on this mystery connection type.
please tell me more, where do you see the deadlock?
In SQL Server on this query (it just happened again)
(@P1 int,@P2 bigint,@P3 int,@P4 datetime2,@P5 nvarchar(9),@P6 bigint,@P7 bigint)UPDATE NUMBERSEQUENCELIST SET STATUS=@P1,TRANSID=@P2,RECVERSION=@P3,MODIFIEDDATETIME=@P4,MODIFIEDBY=@P5,MODIFIEDTRANSACTIONID=@P6 WHERE (RECID=@P7)
- do you have numbsersequences on continue, and did they do a clean up at that time?
- also use traceparser on the AOS, this will tell you the table an related calls (stack trace)
- do users experience anything wrong?
Yes, I have the stack, and I'm sure the user is experiencing an error (my bet is on unbalanced TTS), but my question is about the connection type, not so much about the lock :)
you get the lock that you deserve :-(
is read committed snapshot active?
please show me the stack