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

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

К>В связи с такими задачами и был придуман механизм асинхронного вызова. Для этого в 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 минут