Шаблон Akka для создания экземпляра актера, только если объект, который он представляет, был ранее создан?

Как я могу загрузить только актера, если он ранее был официально создан в соответствии с правилами домена? Все, что я видел, используя actorOf и постоянство, всегда создает пустой экземпляр, а затем применяет [возможно пустой] набор событий, которые произошли, тогда как я бы предпочел сделать пустые экземпляры непредставимыми. Есть ли стандартный подход для запроса «созданного» события и иного запуска сбоя через «не найдено»?

Я считаю, что нужно иметь по одному экземпляру актора для каждого объекта в системе, но я ожидаю, что менее 10% объектов будут активно требоваться в любой момент времени, поэтому я стараюсь избегать загрузки всего набора только для проверки действительности. при обработке запроса.

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


scala akka akka-persistence
person ryachza    schedule 04.09.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я думаю, вы говорите о PersistentActors. Нет api для предварительного сохранения состояния вне PersistentActor. Идея в том, что актер сам следит за своим состоянием. Пустые акторы не приносят никакой пользы, акторы должны сохранять какое-то состояние, поэтому, когда вы инициализируете его через actorOf, оно должно иметь вид состояния Created. С другой стороны, не следует думать, что он сохранил свое состояние, пока не сообщит создателю, что оно было сохранено.

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

person Kirill Yankov    schedule 04.09.2018
comment
Спасибо. Да PersistentActor. Мне пришла в голову мысль о творчестве как части актерского состояния - это правильный / лучший подход? Меня беспокоит то, что требование к супервизору проверять созданное состояние его дочерних элементов, похоже, нарушает инкапсуляцию. Я бы предпочел сбой триггера дочернего экземпляра во время загрузки / инициализации - известно ли вам что-нибудь в жизненном цикле актора, которое позволяет инкапсулировать такого рода проверки предварительных условий? На другом конце у меня будет похожий сценарий, когда дело доходит до удаления. - person ryachza; 04.09.2018
comment
Если у вас нет внешнего состояния (например, базы данных), где вы можете точно проверить существование объекта-актора, тогда вы можете попытаться только инициализировать актера, а затем отправить текущее состояние актера от самого актера к тому, который возможность проверить правильность его состояния или нет. Это зависит от конкретного случая, как лучше проверять (супервизором или каким-либо субъектом проверки состояния) и кто должен останавливать ее в случае неправильного состояния. - person Kirill Yankov; 05.09.2018
comment
Проверка базы данных решит необходимость хранить список допустимых сущностей внутри супервизора, но мне бы не нужна эта внеполосная логика. Наличие актера, проверяющего состояние, просто перекладывает ответственность на какую-то другую третью сторону, и я возвращаюсь к тому, с чего начал. Итак, нет ли способа инициализации актера указать на сбой? Или, возможно, я неправильно обо всем этом думаю, и мне действительно не следует привязывать актера к экземпляру сущности, и в этом случае какой подход мне следует использовать? - person ryachza; 05.09.2018
comment
Это очень абстрактно, реализация зависит от конкретного случая. Чтобы указать на сбой, вы можете просто вызвать исключение в акторе и переопределить SupervisionStrategy родительского актора. Вы также можете подписаться на сообщение Terminated от дочернего элемента, вызвав context.watch(childActorRef) в родительском - person Kirill Yankov; 05.09.2018