Какова хорошая стратегия для работы с жизненным циклом услуг Durable WCF? - PullRequest
1 голос
/ 26 января 2010

Я играю с сервисами Durable WCF. т.е. службы WCF, которые сохраняют свое состояние (в моем случае в базе данных сервера sql) между вызовами методов.

Я хотел бы иметь возможность использовать такие долговечные компоненты либо в операциях Workflow, либо в приложениях Asp.Net, либо в обоих случаях.

Я понимаю, как настроить эти компоненты, чтобы они сохранили свои данные и как заставить их удалить их постоянство. Однако я зациклен на том, как я могу гарантировать, что они всегда правильно удаляют информацию о своем постоянстве из базы данных Sql Server.

Например, допустим, что я подключаюсь к компоненту Durable WCF из приложения Asp.Net. Я могу поместить его контекст в сессию и затем восстановить его из любого места в моем приложении. Я могу перехватить Session_End в файле Global.asax и сказать компоненту, что он больше не нужен.

Кроме - как насчет того, когда Session_End не срабатывает должным образом (по какой-либо причине)?

Допустим, я хочу использовать тот же компонент Durable для других вещей за пределами Asp.Net, где нет сеанса и где может потребоваться, чтобы состояние оставалось на несколько дней или недель между вызовами.

Существует ли уже стандартный способ очистки информации о постоянстве, когда она больше не нужна? Как вы можете точно сказать, если он больше не нужен? Что бы вы предложили?

1 Ответ

1 голос
/ 27 января 2010

Не уверен, что у меня есть "великолепный" ответ, но как насчет того, чтобы просто иметь дату "последнего доступа" в вашей таблице, и если она старше порогового значения, например, 3 месяца, выбросить эти "скелеты" сообщений от вашегоТаблица?

Всякий раз, когда ваша служба WCF что-то делает с постоянным состоянием, убедитесь, что поле даты / времени обновляется.Если он лежал и казался мертвым в течение определенного времени, выбросьте его.Если он выглядит мертвым, пахнет мертвым и не реагирует - это зомби.: -)

Хитрость заключается в том, чтобы найти «правильный» порог, например тот, который не убивает слишком много сообщений «нежити», но также не позволяет зомби загромождать вашу базу данных.Хитрое дело!Это действительно сводится к тому, что вы сами разбираетесь в системе - боюсь, никаких золотых правил.

...