Developers can write data access application that enables ideal connection resiliency with the .NET framework. An idle connection is the one that is active but it’s not executing a command or waiting for data. It is very important to understand how idle connection is reconnecting back in the .NET framework with SQL Server. This white paper actually discusses the same in very simple works. The user has to connect either to a SQL Server 2014 or Microsoft Azure, SQL Database to enable idle connection resiliency.
Here is a very interesting example in the of the idle connection resiliency provided in the Overview section of the Whitepaper.
Let’s imagine that you are a roaming worker that needs to use an Access application to connect to SQL Server. When you need to move from meeting to meeting, you normally close your notebook’s lid in order to move. In working online, every time this happens, you may end up disconnected either because your notebooks sleep or due to blind wireless spots in your building. To avoid the hassle of being disconnected, you may choose to avoid certain places (like elevators, for example) and walk with your notebook’s lid open. Now, imagine if you can close your lid and walk anywhere in your building (even take the elevator) and just arrive to your next meeting, open your lid and find your work there, waiting for you to continue. To address this and other scenarios when an idle connection drops, SQL Server introduced a new feature called Idle Connection Resiliency.
Well, that’s it. This white paper describes the internal working of the Idle Connection Resiliency. It further discusses about the Client’s idle connection, reconnect logic, Client session state handling and replay logic, Non-recoverable session states, and General Considerations.
Click here to read the white paper on Idle Connection Resiliency.
Reference:Â Pinal Dave (https://blog.sqlauthority.com)
