Есть ли способ использовать OperationContextScope, не нарушая сохранение и выгрузку в режиме ожидания?

У меня есть несколько служб рабочего процесса 4 с активностью OperationContextScope, обернутой вокруг пар Receive / SendReplyToReceive, чтобы получить доступ к объекту OperationContext.Current. Действие OperationContextScope взято из CTP пакета безопасности WF по адресу http://wf.codeplex.com/releases/view/48114. Я использую Windows Server AppFabric для хостинга.

Я только что обнаружил, что OperationContextScope устанавливает зону непостоянства. Поскольку OperationContextScope используется путем обертывания последовательности, начинающейся с Receive и заканчивающейся SendReplyToReceive, сохранение не может иметь место в то время, когда рабочий процесс достигает Receive.

Это вызывает проблему, поскольку я настроил AppFabric для немедленного сохранения, когда рабочий процесс становится неактивным, и он становится неактивным, когда достигает действия приема. Упорство не происходит. Я также настроил AppFabric для выгрузки простоя через 60 секунд. Итак, после 60 секунд простоя на приеме мой экземпляр стирается из памяти, но без сохранения.

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

Мне кажется, что у действия OperationContextScope есть недостаток дизайна, так как он предотвращает автоматическое сохранение и выгрузку экземпляров, которые должны происходить должным образом. Или я неправильно использую действие?


.net appfabric workflow-foundation-4
person jonsb    schedule 16.04.2012    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Проблема в том, что OperationContextScope предоставляет вам данные из внешнего текущего вызова WCF. Сам по себе этот вызов не переходит в спящий режим и не возобновляется, как рабочий процесс. На другой стороне этого вызова есть кто-то, ожидающий ответа и, как правило, какое-то сетевое соединение, которое не может быть восстановлено волшебным образом, когда рабочий процесс, наконец, просыпается.

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

person Drew Marsh    schedule 16.04.2012
comment
Я пытаюсь сказать, что экземпляр рабочего процесса становится бездействующим, когда он достигает приема приема, и полезно сохранять и выгружать экземпляр после простоя на этом приеме в течение некоторого времени, поскольку в длительном рабочем процессе это может занять несколько дней или дней. за несколько недель до фактического звонка. Другое дело, что происходит во время разговора, и я не хочу в это время упорствовать. - person jonsb; 17.04.2012