I'm working with a developer who is struggling to stop the following error:
The server will drop the connection, because the client driver has sent multiple requests while the session is in single-user mode. This error occurs when a client sends a request to reset the connection while there are batches still running in the session, or when the client sends a request while the session is resetting a connection. Please contact the client driver vendor.
When this error occurs, a typical outcome is a session that is holding locks, but has no SQL running (no row in
sys.dm_exec_requests for the session_id), and causes blocking until it is killed. The cause of the blocking is straightforward, but how to stop the error from occurring is not.
Some facts about the problem:
- The client is using Entity Framework (yes, I know...), with MARS enabled (yes, I know...)
- SQL Server version is 10.00.5844 (SQL Server 2008 SP3 CU12). They probably won't upgrade major versions without extensive testing, but applying a newer CU is viable.
- The client program shows up in
sys.dm_exec_connectionsas .Net SqlClient Data Provider
- The open connection appears to definitely have MARS enabled, as
- I'm told the application's connection string has asynchronous processing enabled, per Matt Neerincx's comment in this thread (I don't have access to the application servers to confirm this myself):
If you set Async=true on the connection string it should prevent this problem. If you are using MARS and using the same connection on multiple concurrent threads what can happen is the call to reset the connection can get slightly delayed and trigger this error. If you set Async=true we perform additional locking in the client driver to prevent this from happening.
Further information about this error is scarce. It appears to suggest that the client's program is calling
sp_reset_connection while a batch is still running. I could set up a trace to confirm this, but I'd have to record quite a lot of unrelated activity, and the problem is only happening once every few days. Further, I'm not sure that the developer would be able to take advantage of this evidence in order to solve the problem.
Is there any other technique I can use as a DBA or sysadmin to troubleshoot this further, or anything I can suggest to the developer that might provide him with useful information or make the problem less likely to happen?