Использование рабочего процесса Windows в приложении ASP.NET AJAX

Question

Я использую Windows Workflow как часть библиотеки классов в приложении ASP.NET. Я прочитал все предложения по настройке WWF в ASP.NET и с помощью HandWorkflowSchedulerservice, однако я не уверен, что это имеет смысл для моего приложения.

Мои рабочие процессы являются последовательными, без настойчивости; они огонь и забывают. Клиент делает запрос и возвращается позже, чтобы увидеть результаты (или ждет в приложении). До сих пор я использовал класс веб-сервисов AJAX, чтобы уволить работу.

function DoWebserviceJob() 
{ 
    MywebService.DoJob(onComplete, onFailed); 
} 

[WebMethod] 
public DoJob() 
{ 
    //code from library 
} 

Если клиент все еще был рядом, он получил бы уведомление, если бы не все было в порядке. Теперь я использую WWF вместо кодирования прямо из библиотеки. Я знаю, что это работает (с тех пор как я это сделал), но мне интересно, есть ли какие-то побочные эффекты, о которых я не знаю или о других проблемах. Мой новый код выглядит следующим образом:

[WebMethod] 
public DoJob() 
{ 
    WorkflowRuntime runtime = Application["RUNTIME"] as WorkflowRuntime; 
    MyWorkflowManager.DoJob(runtime); 
} 

Мой класс Библиотека:

public void DoJob(WorkflowRuntime runtime) 
{ 
    WorkflowInstance instance = runtime.CreateWorkflow(typeof(MyWorkflow)); 
    instance.Start(); 
} 

Это немного упрощена, но в целом процесс здесь. Это прекрасно работает сейчас, есть ли какие-то вопросы, над которыми я должен быть заинтересован? Если это потоки (что, по-видимому, наиболее часто упоминается), Iis это не то же самое, что и webservice, срабатывающий в другом потоке?

Answer 1

Очень сложно дать вам хороший ответ, так как есть много неизвестных, но я дам это шоу в любом случае.

Наиболее часто встречающаяся проблема с ASP.NET и WF заключается в том, что оба используют ThreadPool и не знают друг о друге. Эта проблема зависит в основном от вашего сайта ASP.NET: WF по умолчанию использует только несколько потоков в ThreadPool (4 на proc для выполнения рабочих процессов и другой для среды выполнения). Проблема обычно решается с помощью ручного WF-планировщика, поскольку WF затем использует хост-поток, то есть тот, который используется ASP.NET. Теперь это может быть хорошим или плохим в зависимости от ваших потребностей. Прежде всего размер ThreadPool растет, и теперь он составляет до 250 потоков на proc, поэтому головоломка ThreadPool вряд ли будет проблемой, если это не сайт с высокой нагрузкой. Недостатком использования ручного планировщика является то, что все запросы, т.е. instance.Start(), становятся синхронными. Если вам нужно что-то из рабочего процесса, чтобы завершить запрос, но если он включен, и забудьте, что ваш запрос ASP.NET теперь ожидает завершения рабочего процесса или достижения некоторого состояния бездействия. Поэтому в некоторых случаях вам будет лучше с планировщиком по умолчанию в вашем приложении ASP.NET, все зависит от того, что вы делаете, и загрузки сервера.

Следует иметь в виду, что IIS будет утилизировать AppDomain через определенное время, по моему мнению, 25 часов по умолчанию или количество запросов. Когда это происходит, среда выполнения WF уничтожается и, следуя следующему запросу, воссоздается в другом AppDomain. Если вы не используете персистенцию, все ваше рабочее состояние будет потеряно, а существующие рабочие процессы будут прекращены. В зависимости от того, сколько времени займет рабочий процесс, это может быть проблемой, а может и не быть, трудно сказать с моей стороны.