Правила наследования весенних @Transactional

Question

У меня есть набор из @Service beans, которые наследуют функциональность ядра от абстрактного класса. Я обозначил каждый из конкретных услуг подкласса @Service и @Transactional. Абстрактный суперкласс содержит метод публичной точки входа для каждой из этих служб. Другими словами, у меня есть что-то похожее на следующее:

abstract class AbstractService { 

    public void process() { 
     // Do common initialisation code here 
     processSpecific(); 
     // Do common completion code here 
    } 

    abstract protected void processSpecific(); 
} 


@Service @Transactional 
public class FirstSpecificService extends AbstractService { 
    protected void processSpecific() { 
     // Do specific processing code here 
    } 
} 


@Service @Transactional 
public class SecondSpecificService extends AbstractService { 
    protected void processSpecific() { 
     // Do different specific processing code here 
    } 
} 

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

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

Однако, если я аннотировать абстрактный супер-класс с @Transactional, то транзакцией является созданы должным образом, и суб-звонки в DAO слой все участвуют в текущей транзакции.

Так что мой вопрос в том, какие правила наследуют поведение @Transactional? Почему Spring не использует @Transactional в конкретных проектах подкласса, которые он фактически создает? Должен ли @Transactional быть в суперклассе в этом случае, потому что именно здесь используется общедоступный метод входа?

Answer 1

Из документации сделки пружинной,

Примечание: В режиме прокси (который по умолчанию), только «внешний» метод звонки, поступающие через прокси-сервер будет перехвачена. Это означает, что «самообзвон» , т. Е. Метод в целевом объекте, вызывающий другой метод целевого объекта, не приведет к фактической транзакции во время выполнения, даже если вызываемый метод отмечен @Transactional!

Даже если у вас есть @Transactional на вашей конкретной реализации, и вы вызываете метод обработки, который на самом деле TRANSACTIONAL ваша аннотация, но этот метод вызывающего процесса processSpecific на ваших подклассах не является транзакционным из-за этот внутренний вызов.

Посмотрите на ткачество.

Answer 2

Вы прочитали часть о transaction propagation и как ее можно настроить с помощью @Transactional?

Еще одна интересная тема: Spring рекомендует, чтобы вы должны были annotate concrete classes (как и против аннотированных интерфейсов).