Axon - SubscribeingEvent против процессора TrackingEvent - PullRequest
1 голос
/ 06 марта 2019

В настоящее время я использую процессор SubscribeingEvent в Axon. Используя это, все выполняется в одном потоке (так как я хочу выполнить команду и применить события к проекции в одном потоке), убедившись, что либо все сохраняется в БД, либо все откатывается.

Что происходит в случае, если мы используем процессор TrackingEvent, если эта команда успешно выполняется в Aggregate и что события, которые генерирует Aggregate, сохраняются в БД, но приложение завершается ошибкой непосредственно перед выполнением проекций (что означает, что они не сохраняются в БД)? Будет ли приложение после перезапуска продолжать проецировать эти события?

В моем случае я делаю проекцию на вызов REST, поэтому я думаю, что для меня имеет смысл использовать процессор SubscribeingEvent (так что либо все в порядке, либо ничего нет). Если бы я использовал процессор TrackingEvent, и приложение зависало между сохранением и проецированием - у меня было бы несовместимое состояние. И даже если проекция будет перезапущена при следующей загрузке (как я полагаю), клиент снова отправит ту же команду (думая, что она не удалась), но что произойдет в совокупности, если он получит ту же команду во второй раз?

1 Ответ

1 голос
/ 11 марта 2019

позвольте мне попытаться дать вам некоторое представление об этом!

Что произойдет, если мы используем процессор TrackingEvent, если эта команда успешно выполнена в Aggregate и что события, которые генерирует Aggregate, сохраняются в БД, но приложение завершается ошибкой непосредственно перед выполнением проекций (что означает, что они не сохраняются в БД)?

TrackingEventProcessor в Axon отслеживает, какие события он обработал, с помощью TrackingToken. Процессор отслеживания обновит TrackingToken только после того, как будут вызваны все компоненты обработки событий (например, компоненты, обновляющие ваши прогнозы). Таким образом, при перезапуске в этот момент процессор отслеживания снова обработает событие. При этом он пытается быть в курсе всего потока событий.

В случае использования процессора TrackingEvent и сбоя приложения между сохранением и проекцией - у меня будет несовместимое состояние.

Это зависит от того, как вы реализовали свое приложение. Звучит так, как будто все тесно связано и при этом не учитывается тот факт, что вам придется иметь дело с возможной последовательностью. Я знаю, что это легче сказать, чем сделать, но если ваш пользовательский интерфейс не ожидает немедленного ответа, когда вы вводите команду, это в конечном итоге упростит систему. Опять же, это сильно зависит от того, можете ли вы повлиять на точку зрения пользовательского интерфейса на выполнение каких-либо действий; не уверен, что это вариант в вашей ситуации.

И даже если проекция будет перезапущена при следующей загрузке (как я полагаю), клиент снова отправит ту же команду (думая, что она не выполнена), но что произойдет в совокупности, если он получит ту же команду во второй раз?

Это полностью зависит от того, как вы реализовали свой агрегат. Агрегат должен принять решение, может ли команда быть выполнена или нет. Если часть процесса принятия решения гарантирует, что предыдущая команда не была идентична текущей операции, то вам нужно будет принять это во внимание в @CommandHandler аннотированных функциях.

Я надеюсь, что это даст вам некоторое представление о Бояне и, не стесняйтесь, ответьте на дополнительные вопросы, чтобы получить контроль над этой частью Аксона.

...