Обработка параллелизма на уровне приложения - какие у меня варианты?

Question

У нас есть тонкий веб-слой ( Scalatra ), который преобразует входящие HTTP-запросы в события (классы дел), которые отправляются привязанному к потоку обработчику событий. Некоторые из событий содержат идентификатор агрегатного корня, который нам нужно мутировать по разным причинам. Общий объем данных приложения слишком велик, чтобы поместиться в памяти, поэтому нам нужно извлечь агрегат по его идентификатору из источника данных, прежде чем работать с ним. Конечно, мы не хотим, чтобы субъект обработки событий блокировал, поэтому идея состоит в том, чтобы создать новый ( основанный на событиях? ) субъект, который загружает данные, изменяет их и сохраняет обратно в источник данных. , В идеале я хотел бы обрабатывать параллелизм в приложении, а не полагаться на возможности ACID источника данных. В основном мне нужен сериализованный / транзакционный доступ к каждому агрегату.

Может ли это быть достигнуто с помощью актеров? Какой будет лучший подход? Хранить ConcurrentHashMap внутри субъекта обработки событий, содержащего субъекты, на которых указан агрегированный корневой идентификатор?

Или мы должны задействовать STM: s (ScalaSTM / Akka) или что-то подобное?

Answer 1

Вы можете представить ваш «совокупный корень» как субъект . Если вы хотите изменить совокупный корень, вы можете отправить сообщение об этом от вашего субъекта обработки запросов. У вас также может быть посредник-посредник, который перенаправляет сообщения нужному субъекту и управляет кэшем совокупных корневых субъектов (по идентификатору) , создавая экземпляр субъекта, представляющий данные по запросу, и останавливая их при необходимости. STM понадобится, если вам нужно скоординировать мутацию между субъектами, которые представляют данные.