tepkaМне почему то, кажется, что данное поведение должен обеспечивает атрибут propagation т.е. нужно заменить @Transactional на @Transactional(propagation = Propagation.REQUIRES_NEW) у метода doProcessing(). Но я так пробовал - не работает. Т.е. пока doProcessing() не закончит свои дела коммитов в postingSchedule не появляется.
Всё верно. Но во-первых REQUIRES_NEW (или даже NESTED) должен стоять у postingSchedule. Во-вторых это всё равно не отработает так как оба метода у вас в одном классе. Транзакции спринг обеспечивает оборачивая классы в прокси. Но когда один метод класса вызывает другой метод того же класса, то вызов идёт мимо прокси и спринг никак не может его перехватить и обработать.

Направление мысли у вас правильное. Нужно использовать Propagation. Но класс стоит разбить на отдельные. Один будет отвечать только за scheduled задачи. Второй за саму обработку. Тогда управление транзакциями будет работать без проблем.
Можно, конечно и по-извращатся, вызывая вместо this.postingSchedule() этот же метод но у проксированого бина полученого из контекста.

tepkaКоммиты хочу получить от вложенной транзакции)
То есть NESTED? Или всё же просто независимая транзакция нужна? Тогда REQUIRES_NEW.

tepkaИМХО не совсем так.
Подкрепить стоит чем-то кроме своего имха.

tepkaВ доке написано, что аннотация @Transactional на методе, срабатывает по умолчанию (т.е. есть видимо какой то способ, не только по умолчанию)
Ну, как бы да. Методы все считаются как Propagation.REQUIRED - есть транзакиця, используется. Нет - создаётся новая. И можно ссылку на доку, которую вы используете. Уж больно вольная у вас трактовка.

tepkaтолько, когда этот метод вызывается из вне. А не внутри класса.
Ну, так а я о чем?

tepkaЕсли класс разбить на два класса, то Propagation будет не нужен. Не ясно тогда назначение этого атрибута Propagation.
Т.е. назначение не ясно, но вы твердо уверены что не нужен? По-умолчанию используется Propagation.REQUIRED. То что вы хотите это REQUIRES_NEW или NESTED. Какая именно из них вам нужнее, пока не ясно.

tepka1) Что есть еще какой то способ по мимо proxy mode.

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

tepka2) Аннотация @Transactional имеет смысл быть только у внешних методов.

Внутренний\внешний методы это не объективный атрибут метода. Это только способ, которым метод вызывается.

tepkaТ.е. если она будет стоять у внутренних методов класса она будет просто проигнорирована.

Не совсем. Просто вызов пойдёт мимо прокси, в которой реализован AOP. Можно вызвать тот же метод, использую ссылку на прокси. Метод от этого не перестанет быть "внутренним". Но АОП уже отработает нормально.

tepkaТ.е. фраза "REQUIRES_NEW (или даже NESTED) должен стоять у postingSchedule" от Blazkowicz не имеет смысла.

Выводы у тебя не адекватные. Я подробно изложил, почему это не будет работать в твоём случае и как эту проблему решить.

tepkaТак как атрибут propagation ставится у аннотации Transactional внутреннего метода.

Нет такого понятия как "внутренний метод". Есть понятие "внутренний вызов" - вызов метода внутри класса через ссылку this, мимо спринговой прокси, которая реализует AOP.

tepkaА так же я все таки попробовал поставить Propagation.REQUIRES_NEW у метода postingSchedule и это не помогло.

Удивительно. Наверное потоум что "вызов метода внутри класса через ссылку this идёт, мимо спринговой прокси, которая реализует AOP", о чем я уже раз 5й в этой теме пишу.

tepkaПока doProcessing() не закончит свою работу, коммиты (postingDAO.saveOrUpdate(postingScheduleEntity)) внутри postingSchedule не появляются.
Ещё раз объяснить почему?

tepkaНо я просто хочу разобраться с какой целью придумали Propagation, если он не работает.
Ну, вот почему сразу "он не работает". С чего ты решил, что Propagation не работает. Не работет Spring AOP когда он реализован через прокси а вызовы методов происходят мимо прокси. Что просто и логично. Это никак не связано с тем что не работает Propagation.

В целом, совет один. Отложи в сторону вопрос транзакций, и разберись с тем что такое АОП и как именно оно реализовано в Spring.

tepkaЧего то я не догоняю точно)
С английским текстом тоже нужно поточнее обращатся.
external method call это не "внешний метод", это "внешний вызов метода".
Что любопытно в указанном переводе это тоже достаточно корректно отражено. А у тебя появились какие-то внутренние и внешние методы.

Йуный джавистЪЯ думал, что для класса


Спринг генерит


В таком варианте проблем не должно быть
Как раз проблема в том, что если вызывать FooService.foostuff(), то прокси про это никогда ничего не узнает. Что и происходит у автора темы.
А вот если настроить AspecJ weaving, то do some magic будет добавлен непосредственно в FooService. Тогда проблемы стем чтобы получить ссылку на прокси не будет. Так как не будет и самой прокси.