|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
Собственно вопрос в сабже. MS официально это не описывает, описание CommandTimeout очень скудное. Если контролируют и provider, и сервер, то очень вероятен вариант рассинхронизации - когда сервер транзакцию выполнил и вернул ответ, а клиент не успел все стянуть из-за слабой сети и вернул ошибку. Т.е. транзакция завершена успешно на сервере, а я на клиенте думаю что нет! Если только сервер, то тогда из-за проблем с TCP соеднинением клиент в теории может ждать ответа бесконечно долго. Если только provider, то понятно что невозможно из-за риска прихода след. команды пока висит в обработке пред. В общем, где можно подробно прочитать? Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 16:10 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
victorov1, сервер таймауты при выполнении не устаивает, иначе возникнет ошибка, о которой Вы писали. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 16:13 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
Владислав Колосов, С чего бы сервер не устанавливает? Смотря где ) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 16:26 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
Клиент перед выполнением команды говорит серверу - если команда выполняется более CommandTimeout - значит что-то пошло не так, пристрели ее, верни ошибку, будем разбиратся. Входит ли в этот таймаут время фетча - не знаю. Также было бы интересно есть ли способ поменять дефолтные 30 секунд на что нибудь другое не перекомпилируя приложение. (типа в реестре у клиента подкрутить, чтобы поменять дефолт на 1 минуту) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 16:31 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
Критик, это же коннекты, а не рантайм. По крайне мере, запросы через 10 минут не отваливаются. Скорее всего. эта настройка для связанных серверов. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 16:33 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
Критик, не стоит путать remote query timeout настроек конфигурации сервера который задается через sp_configure с настройками клиента SqlClient. remote query timeout задает время ожидания для исходящих запросов от конкретного экземпляра сервера. в данном случае применительно к установке ожидания для запросов через линкованные сервера. victorov1, настройка же commandTimeout это настройка клиента задаваемая свойством для объекта экземпляра SqlCommand. явно ее можно выставить через строку соединения/или непосредственно само свойство объекта, но дефолтного значения через правку реестра и прочих танцов с бубнами нет ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 17:22 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 17:26 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
felix_ff Критик, не стоит путать remote query timeout настроек конфигурации сервера который задается через sp_configure с настройками клиента SqlClient. remote query timeout задает время ожидания для исходящих запросов от конкретного экземпляра сервера. в данном случае применительно к установке ожидания для запросов через линкованные сервера. victorov1, настройка же commandTimeout это настройка клиента задаваемая свойством для объекта экземпляра SqlCommand. явно ее можно выставить через строку соединения/или непосредственно само свойство объекта, но дефолтного значения через правку реестра и прочих танцов с бубнами нет В реестре я ничего и не собирался менять. Мне важно понять логику. Если сервер бесконечно отрабатывает транзакцию (или до обрыва соединения с клиентом) и не принимает ConnectionTimeout от провайдера, то как будет все работать если клиент отвалится в ходе выполнения длительной транзакции и TCP_FIN не был отправлен из-за обрыва кабеля или чего-то еще? Т.е. сервер будет думать, что клиент еще висит и ждет (TCP-соединение формально не оборвано), а он (клиент) давно отвалился, получил Query Timeout от ADO и возможно переподключился снова и снова попытался выполнить тот же долгий SQL-запрос, т.к. предыдущий был завершен с таймаутом. В итоге можем получить ситуацию, при которой сервер нагнется из-за бесконечного числа параллельных тяжелых запросов. Я пытался снифферить трафик между провайдером и сервером - так вот никакие poll периодические там не отправляются. Т.е. в теории описанный мною сценарий теоретически возможен. Но это ж пипец, товарищи! Наверняка же все это учтено и все не так плохо? Как предотвратить? Т.е. если я получил Query Timeout, как узнать что сервер действительно отменил эту транзакцию в данный момент? Или, если это невозможно, то тогда нужно обрывать соединение принудительно, но как я описал выше - способ тоже ненадежный. Более надежнее было серверу также ориентироваться на CommandTimeout. Похоже придется тупо экспериментировать... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 17:45 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 18:18 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
спасибо, буду разбираться ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 18:39 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
invm Так это настройки на клиенте, а не сервере. Это клиент посылает keepalives серверу, а не наоборот. А как сервер будет знать, что клиент отвалился если тот не прислал TCP FIN по какой-то причине? Получается будет висеть и выполнять транзакцию пока не выполнит. Но главный то вопрос в следующем: если ADO вернуло ошибку таймаута, получается на 100% мы не можем быть уверены, что транзакция не выполнена. Она может быть выполнена успешно за долю секунды до этого, но клиент просто не успел считать данные. И еще кейс: транзакция долго выполняется, ADO вернуло ошибку таймаута, отменится ли данная транзакция на сервере? Как-то в документации об этом четко не написано: f the interval set in the CommandTimeout property elapses before the command completes execution, an error occurs and ADO cancels the command. Что такое "cancels the command" непонятно. Означает ли это отмену транзакции или нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 18:52 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
victorov1 invm Так это настройки на клиенте, а не сервере. Это клиент посылает keepalives серверу, а не наоборот. А как сервер будет знать, что клиент отвалился если тот не прислал TCP FIN по какой-то причине? Получается будет висеть и выполнять транзакцию пока не выполнит. Но главный то вопрос в следующем: если ADO вернуло ошибку таймаута, получается на 100% мы не можем быть уверены, что транзакция не выполнена. Она может быть выполнена успешно за долю секунды до этого, но клиент просто не успел считать данные. И еще кейс: транзакция долго выполняется, ADO вернуло ошибку таймаута, отменится ли данная транзакция на сервере? Как-то в документации об этом четко не написано: if the interval set in the CommandTimeout property elapses before the command completes execution, an error occurs and ADO cancels the command. Что такое "cancels the command" непонятно. Означает ли это отмену транзакции или нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 18:58 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
victorov1 Так это настройки на клиенте, а не сервере. victorov1 Это клиент посылает keepalives серверу, а не наоборот. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 19:31 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
felix_ff, Я в курсе, даже наступил на это разок со связанными серверами. Просто выше написано, что "сервер не устанавливает таймауты". Иногда устанавливает. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 19:35 |
|
кто контролирует CommandTimeout - сервер, provider, или оба?
|
|||
---|---|---|---|
#18+
Критик, речь шла о конкретном сценарии, а не "вообще во вселенной". Не надо подменять факты. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2021, 21:05 |
|
|
start [/forum/topic.php?fid=46&fpage=22&tid=1684598]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
76ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
others: | 10ms |
total: | 184ms |
0 / 0 |