Критик,
не стоит путать remote query timeout настроек конфигурации сервера который задается через sp_configure с настройками клиента SqlClient.
remote query timeout задает время ожидания для исходящих запросов от конкретного экземпляра сервера. в данном случае применительно к установке ожидания для запросов через линкованные сервера.
victorov1,
настройка же commandTimeout это настройка клиента задаваемая свойством для объекта экземпляра SqlCommand.
явно ее можно выставить через строку соединения/или непосредственно само свойство объекта, но дефолтного значения через правку реестра и прочих танцов с бубнами нет
В реестре я ничего и не собирался менять. Мне важно понять логику.
Если сервер бесконечно отрабатывает транзакцию (или до обрыва соединения с клиентом) и не принимает ConnectionTimeout от провайдера, то как будет все работать если клиент отвалится в ходе выполнения длительной транзакции и TCP_FIN не был отправлен из-за обрыва кабеля или чего-то еще? Т.е. сервер будет думать, что клиент еще висит и ждет (TCP-соединение формально не оборвано), а он (клиент) давно отвалился, получил Query Timeout от ADO и возможно переподключился снова и снова попытался выполнить тот же долгий SQL-запрос, т.к. предыдущий был завершен с таймаутом. В итоге можем получить ситуацию, при которой сервер нагнется из-за бесконечного числа параллельных тяжелых запросов.
Я пытался снифферить трафик между провайдером и сервером - так вот никакие poll периодические там не отправляются. Т.е. в теории описанный мною сценарий теоретически возможен. Но это ж пипец, товарищи!
Наверняка же все это учтено и все не так плохо? Как предотвратить?
Т.е. если я получил Query Timeout, как узнать что сервер действительно отменил эту транзакцию в данный момент? Или, если это невозможно, то тогда нужно обрывать соединение принудительно, но как я описал выше - способ тоже ненадежный.
Более надежнее было серверу также ориентироваться на CommandTimeout.
Похоже придется тупо экспериментировать...
