Куда относится аннотация @Transactional?

Обычным случаем было бы аннотирование службы уровень уровня, но это действительно зависит от ваших требований.

Аннотирование на уровне сервиса приведет к более длительным транзакциям, чем аннотирование на уровне DAO. В зависимости от уровня изоляции транзакции могут возникнуть проблемы, поскольку параллельные транзакции не будут видеть изменения друг друга, например. ПОВТОРНОЕ ЧТЕНИЕ.

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

Нет смысла комментировать оба слоя, если режим распространения установлен по умолчанию.

Транзакционные аннотации следует размещать вокруг всех неотделимых операций.

Например, ваш звонок - «сменить пароль». Это состоит из двух операций:

1. Изменить пароль.
2. Проверить изменение.
3. Отправить клиенту электронное письмо о том, что пароль был изменен.

Таким образом, в приведенном выше случае, если проверка не удалась, следует также изменить пароль. потерпеть поражение? Если это так, то транзакция должна быть около 1 и 2 (так на уровне обслуживания). Если электронное письмо не удалось (вероятно, должно быть какое-то средство защиты от сбоев, чтобы оно не сработало), следует ли откатить изменение пароля и аудит?

Это те вопросы, которые вам нужно задать при принятии решения куда поместить @Transactional .

Кроме того, Spring рекомендует использовать примечания только для конкретных классов, а не для интерфейсов.

http://static.springsource.org/spring/docs/2.0.x/reference/transaction.html

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

Развивающейся тенденцией в Spring является проектирование, ориентированное на домен (DDD). Spring Roo хорошо иллюстрирует эту тенденцию. Идея заключается в том, чтобы сделать POJO доменных объектов намного богаче, чем они есть в типичных архитектурах Spring (обычно они анемичны), и, в частности, наложить семантику транзакций и персистентности на сами доменные объекты. В случаях, когда все, что требуется, это простые операции CRUD, веб-контроллеры работают непосредственно с POJO доменных объектов (в этом контексте они функционируют как сущности), и нет никакого сервисного уровня. В случаях, когда между доменными объектами требуется некая координация, вы можете поручить это сервисным бобам, используя @Transaction в соответствии с традицией. Вы можете установить распространение транзакций на объектах домена на что-то вроде REQUIRED, чтобы объекты домена использовали все существующие транзакции, например, транзакции, которые были запущены на сервисном бине.

Технически эта техника использует AspectJ и . Roo использует межтиповые определения AspectJ для отделения семантики сущности (транзакции и персистентность) от вещей доменного объекта (в основном поля и бизнес-методы).

Лучше иметь в сервисном слое! Это ясно объясняется в одной из статей, на которые я наткнулся вчера! Вот ссылка , которую вы можете проверить!