Срок службы обработчика сообщений - PullRequest
2 голосов
/ 20 июля 2011

Каков рекомендуемый срок службы обработчика сообщений?

Моя текущая реализация вызывает несколько проблем, особенно когда речь идет о доступе к данным (NHibernate).

Наша текущая реализация выглядит следующим образом:

Клиентское приложение(Интернет)
Отправляет сообщения в очередь (в памяти, msmq, azure)

Рабочее приложение (служба Windows)
Опрашивает очереди и передаетсообщения зарегистрированным обработчикам.

Когда мы инициализируем работника, мы регистрируем наши обработчики.Обработчики загружаются лениво (используя Lazy<T>), поэтому они не создаются до тех пор, пока процессор очереди не запустится (в другом потоке).

Когда обработчики инициализируются , мы заполняемих зависимости и они хранятся в памяти до тех пор, пока процессор очереди не будет выключен.

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

Какой рекомендуемый подход?

Ответы [ 2 ]

3 голосов
/ 20 июля 2011

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

Если вы используете какую-то единицу работы (NHibernate ISession), то, вероятно, лучше иметь одну на транспортное сообщение как xelibrion sais.Одно транспортное сообщение может содержать больше логических (прикладных) сообщений, которые должны обрабатываться вместе, если они поступили в одном и том же физическом сообщении.

Это делается так в NServiceBus и NanoMessageBus.

1 голос
/ 20 июля 2011

Я предпочитаю сеанс для транспортного сообщения

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