Основа рабочего процесса: никогда не завершается Задержка - PullRequest
Новая
       12

Основа рабочего процесса: никогда не завершается Задержка

1 голос
/ 04 июня 2010

Давайте создадим рабочий процесс, состоящий из действия «Получение» и «Задержки». Активность приема имеет CanCreateInstance = true и корреляция запроса (сообщения) также предоставляется. Рабочий процесс размещен в службе рабочего процесса и сохраняется в базе данных немедленно на холостом ходу. 

WorkflowService service = new WorkflowService
{
  Name = "MyWorkflow",
  Body = new MyWorkflow(),
  Endpoints =
  {
    new Endpoint
    {
      ServiceContractName = "IMyWorkflow",
      AddressUri = new Uri("http://localhost:1234/MyWorkflow"),
      Binding = new BasicHttpBinding()
    }
  }
};

WorkflowServiceHost host = new WorkflowServiceHost(service);
string conn = "Data Source=...;Initial Catalog=...";
host.DurableInstancingOptions.InstanceStore = new SqlWorkflowInstanceStore(conn);
host.Open();

Теперь я отправляю сообщение в рабочий процесс и среда выполнения создает первый экземпляр рабочего процесса. Корреляционный ключ включен в сообщение, конечно. Рабочий процесс продолжается с задержкой и сохраняется в базе данных и выгружается.

Давайте предположим, что задержка достаточно велика, и я отправлю следующее сообщение с точно таким же ключом корреляции. Что просходит? Оба рабочих процесса никогда не просыпаются от задержки и никогда не завершаются.

Что я не прав? Почему время выполнения рабочего процесса не защищает меня от этого? Есть ли способ как спасти оба экземпляра рабочего процесса?

Спасибо за помощь!

1 Ответ

2 голосов
/ 04 июня 2010

Если вы используете корреляцию сообщений, значение ключа в сообщении должно соответствовать одному активному рабочему процессу. Если вы попытаетесь запустить второй рабочий процесс с использованием того же ключа, вы получите исключение при попытке запустить новый экземпляр. Теперь, если вы используете только получение без SendReply, вы создаете одностороннюю схему обмена сообщениями, и нет способа отправить ошибку SOAP обратно клиенту. Таким образом, клиент может не знать об ошибке. Вы все еще можете увидеть это, если включите трассировку в своем сервисе и осмотрите файлы журналов. Однако более простой вариант - включить SendReply, даже если у вас нет нормального ответа, поскольку это приводит к ответному сообщению, которое может содержать сообщение об ошибке.

...