Какой слой должен быть инициатором создании и закрытии транзакции

3

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

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

update: Это если транзакции делаются руками, а не в контейнере.

Поэтому слой модели должен высовывать наружу интерфейсы с методами create, update..., а внутри этих методов уже рулить транзакциями, как ему надо.

А если нужен такой сценарий работы, чтобы creat и update были в одной транзакции, то есть что-то типа такого:

//этот сервис, который вызывает методы бизнесс логики

MyService service = new MyService();
User user = new User("username");
service.AddUser(user);
Order order = service.GetOrder();
user.AddOrder(order);
service.UpdateUser(user);
service.Dispose(); //И тут коммит

Если не добавился ордер для юзера, то и юзера не добавлять

А если нужен такой сценарий работы, чтобы creat и update были в одной транзакции,

Unit of Work

Поэтому слой модели должен высовывать наружу интерфейсы с методами create, update...,

Методы create, update, etc - это DAL, а не слой моделей.

«Стандартное» место это 3.

Еще propagation вполне допустим. То есть можно первый уровень транзакций сделать и в CRUD слое, и в сервисах, и выше, в приложенни на случай если нужно 2 и более бизнес операции сделать в одной трнзакции.

Еще propagation вполне допустим.

А это что такое? гугл ниче толком не дал

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

Тьфу блин, я думал тут про биткоины.

Вот чтобы точно было понятно что нужно:

есть два веб-сервиса, оба они работают с одной БД, нужно выполнить два метода (по одному из каждого сервиса) в одной транзакции.

Как такое можно сделать?

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

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

Отвечу честно, не знаю.

В 3-м. Чаще удобнее бывает еще завести 4-й слой для DAO, чтобы было меньше бардака в 3-м.

Какое нах XA, написано же, что в одну базу ходят. Просто еще один сервис нужно написать, который 2 других дергает в одной транзакции.

@Transactional
public void doMegaMethod() {
  service1.foo();
  service2.bar();
}

Как это реализовано технически могу расскзать. Там не хитрый дизайн.

Как это реализовано технически могу расскзать. Там не хитрый дизайн.

Хотелось бы увидеть. А doMegaMethod() где находится, на каком слое?

Обычно 3, при особых потребностях 2. Используй AOP

На любом.

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

Методы create, update, etc - это DAL, а не слой моделей.

Согласен, просто у меня глупая привычка смотреть на модель как на DAL + domain objects. А так я за него.

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

Браво!

Не браво. Unit of work понятие ортогональное транзакциям. Оно про то, как трекать обновления сущностей и автоматически сбрасывать их состояние в хранилище по окончании сессии.

Сами транзакции и управлении ими - разные вещи. Сами транзакции - это инфра уровень. А вот упроавление через абстрактные интерфейсы вполне можно занести на бизнес-уровень. Ведь есть понятие бизнес-транзакции, которое можно замепить на инфраструктурные транзакции (XA, DB, etc).