У меня возникли трудности с поиском хорошего решения для поддержки этой функции, когда пользовательский интерфейс может запускать и фиксировать транзакцию.
В моих предыдущих подходах к работе с транзакционными приложениями я группировал единицу работы в сервисный метод в бэкенде и аннотировал его с помощью Spring @Transactional.
Но представьте, что у меня есть несколько подобных сервисных методов, и внешний интерфейс должен сгруппировать вызовы сервисных методов внутри транзакции.
Например, у меня есть methodServiceA, methodServiceB, methodServiceC. Пользовательский интерфейс может сделать что-то подобное с любыми комбинациями, такими как:
Комбинация 1:
- начинает транзакцию
- вызов методаServiceA + вызов методаServiceB
- совершает транзакцию
Комбинация 2:
- начинает транзакцию
- вызов методаServiceB + вызов методаServiceC
- совершает транзакцию
Комбинация 3:
- начинает транзакцию
- вызов методаServiceA + вызов методаServiceB + вызов методаServiceC
- совершает транзакцию
По сути, серверная часть предоставляет только метод обслуживания, и это зависит от пользовательского интерфейса или других приложений, которые используют серверную часть для запуска/фиксации транзакции.
Так что это в основном ситуация, с которой я имею дело ... и вот что я имею в виду. Пожалуйста, поделитесь некоторыми другими вариантами или, возможно, улучшениями, которые я мог бы сделать для поддержки этой функции. В настоящее время я думаю об использовании менеджера сущностей, управляемого приложением, так как я не думаю, что использование @Transactional будет работать в этом случае.
Я думаю об объекте, который пользовательский интерфейс или другие соединители могли бы использовать для:
- создать менеджер сущностей и связать его с уникальным идентификатором
- начать транзакцию с em
- установить тайм-аут от em
- зафиксировать транзакцию из em
- автоматически откатывать транзакцию, если есть какие-либо исключения из em
- передает диспетчер сущностей транзакции методам службы, чтобы они использовали один и тот же диспетчер сущностей
- окончательно закрывает менеджер сущностей после фиксации или отката из em
Итак, для примера для Комбинации 1 поток выглядит примерно так:
- ui запускает транзакцию с помощью инструмента и получает идентификатор entitymanager
- передайте идентификатор entitymanager при вызове methodServiceA + вызове methodServiceB, чтобы эти методы могли использовать правильный диспетчер сущностей, который связан с идентификатором
- совершает транзакцию
Поделитесь своими мыслями по этому поводу, спасибо!
Относительно шаблона фасада/команды:
Спасибо за идею. Но я также думал об этом, и я не думаю, что это подходит для наших нужд, поскольку я не могу всегда предоставлять фасадную службу в бэкэнде для любых потребностей (представьте себе каждую кнопку пользовательского интерфейса, которая может комбинировать любые службы методов, которые они хотят), которые возникают.
Основная идея состоит в том, чтобы иметь общедоступные сервисные методы, которые другие клиентские приложения могли бы связывать друг с другом.
Кроме того, использование шаблона фасада означает отсутствие логики пользовательского интерфейса в методе фасада. В нашем случае логика пользовательского интерфейса может выполняться вместе с обработкой транзакций и вызовом сервисных методов во внешнем интерфейсе.
