Здравствуйте.
В связи с таймаутом сессии веб-сервиса возник вопрос. Собственно тема. Т.е., допустим есть некая операция, которая неизвестно сколько времени займет на выполнение — может 10 минут, а может несколько часов, а то и пару дней. Допустимо ли использование веб-сервисов для "оформления" таких длительных по времени задач? Причем клиенту этого сервиса дожидаться ответа не надо. Просто запускается некая задача. Но проставляя значение таймаута веб-сервиса, мы четко лимитируем длительность выполнения запрошенной операции. Таким образом всегда будет шанс, что задача не успеет выполниться. А это мне ен нравиться.

Итого более четко сформулированные вопросы:
1) Запуск из тела веб-метода отдельного потока, который взял бы на себя выполнение длительной операции, не спасает, т.к. через 20 минут он умирает. Я неправ? ОЧЕНЬ хочется верить, что мне показалось :) . Если нет, есть ли возможность обойти такое поведение созданного отдельного потока?
2) Как бы вы оформили такие длительные операции? Принимаются любые советы. Вплоть до "а брось ты этот веб-сервис...". Главное чтоб аргументировано

Здравствуйте, Красин, Вы писали:

К>Здравствуйте, Аноним, Вы писали:

К>В связи с такими задачами и был придуман механизм асинхронного вызова. Для этого в web сервисе делаем методы:
К>
К>public Guid StartOperation();
К>public bool IsOperationFinished(Guid operationId);
К>public void StopOperation(Guid operationId); 
К>
К>В StartOperation начинаем исполнение задачи в другом потоке, регистрируем ее в своей внутренней hash-таблице, где задаче дается ключ в виде guid-а, а в качестве значения идет поток (или номер исполнителя) в котором выполняется задача. После этого возвращаем клиенту этот Guid, не дожидаясь завершения задачи. Семантика двух остальных методов очевидна.

К>Если вам надо только запустить задачу, а контроль и возможность отмены не требуется, то решение упрощается до
К>
К>public void StartOperation();
К>

Спасибо за ответ, но Вы, видимо, невнимательно прочитали то, что писал я:

1) Запуск из тела веб-метода отдельного потока, который взял бы на себя выполнение длительной операции, не спасает, т.к. через 20 минут он умирает. Я неправ? ОЧЕНЬ хочется верить, что мне показалось . Если нет, есть ли возможность обойти такое поведение созданного отдельного потока?
Единственное уточнение. Долго выполняется не просто какой-то код веб-метода, а происходит вызов длительной хранимой процедуры, т.е. мы долго "висим" на вызове command.ExecuteNonQuery(). Причем, если я вызываю эту хранимую процедуру из "основного потока" веб-приложения (взял в кавычки, т.к. незнаю как правильно это называется) и ставлю таймаут сессии допустим 2 часа, то все ок. Но вот создаваемый поток живет только 20 минут :crash:

Здравствуйте, Константин Л., Вы писали:

КЛ>Так у тебя просто таймаут вызова SP. Это к вэбметоду никакого отношения не имеет. Просто увеличь таймаут вызова SP. Кроме того, SOAP поддерживает так называемые one-way вызовы. Те вызовы без получения ответа. Для оформления такого вызова нужно на метод навесить специальный атрибут — SoapDocumentMethodAttribute::OneWay(из System.Web.Services.Protocols)

Спасибо за ответ. Но в конкретно моем случае это не то. С таймаутом вызова SP все в порядке. Эта же процедура (с теми же настройками команды и соединения) из-под Win-приложения выполняется нормально