JPA: applicationManaged EntityManager for Java SE для программного управления жизненным циклом транзакций

Question

Мне трудно найти хорошее решение для поддержки этой функции, где пользовательский интерфейс может запускать и фиксировать транзакцию.

В моих предыдущих подходах к работе с транзакционными приложениями я группировал единицу работы вметод обслуживания в бэкэнде и аннотируйте его с помощью Spring @Transactional.

---

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

Например,У меня есть methodServiceA, methodServiceB, methodServiceC.Пользовательский интерфейс может делать что-то подобное с любыми комбинациями, такими как:

Комбинация 1:

1. запускает транзакцию
2. вызывает methodServiceA + вызывать methodServiceB
3. фиксирует транзакцию

комбинация 2:

1. запускает транзакцию
2. вызывает метод methodServiceB + вызывает methodServiceC
3. фиксирует транзакцию

Комбинация 3:

1. запускает транзакцию
2. вызывает метод methodServiceA + вызывает метод methodServiceB + вызывает метод methodServiceC
3. фиксирует транзакцию

По сути, бэкэнд предоставляет только метод services, и пользовательский интерфейс или другие приложения, использующие бэкэнд, могут запускать / фиксировать транзакцию.

---

Так что в основном это ситуацияЯ имею дело с ... и вот что я имею в виду.Пожалуйста, поделитесь некоторыми другими опциями или, возможно, улучшениями, которые я мог бы внести для поддержки этой функции.В настоящее время я думаю об использовании приложения управляемого объекта, поскольку я не думаю, что в этом случае сработает @Transactional.

Я думаю об объекте, который пользовательский интерфейс или другие соединители могут использовать для:

1. создайте менеджер сущностей и свяжите его с уникальным идентификатором
2. запустите транзакцию из em
3. установите тайм-аут из em
4. зафиксируйте транзакцию изem
5. автоматически откатывает транзакцию, если есть какие-либо исключения из em
6. , который передает менеджер сущности транзакции в методы сервиса, чтобы они использовали один и тот же менеджер сущности
7. наконец закрывает менеджер сущностей после коммита или отката от em

Итак, для примера для Combination 1 поток выглядит примерно так:

1. ui запускает транзакциюиспользуя инструмент, и получите идентификатор entitymanager
2. , передающий идентификатор entitymanager при вызове methodServiceA +, вызывающий methodServiceB, so эти методы могут использовать правильный менеджер сущностей, связанный с идентификатором
3. , который совершает транзакцию

---

Пожалуйста, поделитесь своими идеями по этому вопросу, спасибо!

---

По поводу фасада / шаблона команды:

Спасибо за идею.Но я тоже об этом думал, и я не думаю, что это подходит для наших нужд, поскольку я не всегда могу предоставить услуги фасада в бэкэнде для любых нужд (представьте кнопки каждого пользовательского интерфейса, которые могут комбинировать любые методы, которые они хотят), которые возникают.

Основная идея состоит в том, чтобы иметь общедоступные методы обслуживания, которые могли бы соединять другие приложения веб-интерфейса.

А также, использование шаблона фасада означает отсутствие пользовательской логики в методе фасада.В нашем случае логику пользовательского интерфейса можно выполнить вместе с обработкой транзакций и вызовом методов сервиса во внешнем интерфейсе.

Answer 1

Вы можете попробовать использовать Шаблон команды - пользовательский интерфейс отправляет последовательность команд, а ваш бэкэнд выполняет их в одной транзакции.

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

Answer 2

Используйте шаблон фасада: создайте сервис фасада, содержащий метод для каждой из комбинаций (который должен отображать функциональный вариант использования), и сделайте эти методы фасада транзакционными, используя аннотацию Spring. Методы фасада будут просто вызывать существующие методы обслуживания.