Наверное потому что над scheduleExecutionForTable тоже @Transactional шлепнут.

у спринга для @Transactional конвенция такая, что в случае исключений во "вложенных" (тут специально в кавычках, потому что оно обычно под "nested" для транзакций нечто иное подразумевается) транзакциях, оно при checked exceptions не фейлит транзакцию, а при RuntimeException фейлит, там есть Transactional#noRollbackFor но из опыта могу сказать что оно совершенно бесполезное, например для вашего OptimisticLockException ситуация на самом деле следующая:
- был вызван flush
- flush не прошел
- то что после этого хранится в контексте хибера вообще непонятно и как это компенсировать тоже непонятно, т.е. если бы OptimisticLockException вам транзакцию не фейлил, то вы бы все равно commit бы не смогли выполнить - оно бы столкнулось на том же месте

Чет вы оба неправы: я же тебе показывал вот тут: 22349359 , что транзакции нужно лепить над бизнес-кодом, а над репозиторями и DAO тоже нужно, но особого смысла не имеет. Что касается самих "транзакций в БД": в JDBC (java.sql) нет нигде явного вызова который бы создавал/начинал транзакцию (сюрприз), есть только вызов фиксации или отката, например для хибера "начало транзакции" - это захват соединения из пула и выключение автокоммита, хотя если его хорошо попросить, то он этого делать не будет, а будет надеяться, что автокоммит и так выключен.

Пока есть Стас, который не считает верным лепить в бизнес-коде, в DAO лепить нужно.

Кмк здесь палка о двух концах:
- в целом понятно, что дергать DAO без наличия активной транзакции (а я выше упоминал, что в принципе поднять транзакцию ничего не стоит по ресурсам, кроме того что оно будет соединение держать дольше положенного) особо смысла не имеет: даже если мы что-то успешно понавыбирали, то далеко не факт, что мы сможем дернуть свойства (транзакции-то уже нет), ну а при сохранении выбранного оно будет или падать или уходить в тормознутый merge
- если @Transactional в DAO не лепить вообще, то "клиент" получит возможность перехватывать исключения и не откатывать транзакцию (прямо как у ТС), ничем хорошим это не светит, более того, мы таким образом вытаскиваем кишки нашего DAO на "клиента", здесь было бы хорошо, если бы была полноценная поддержка NESTED, но увы... получается что не лепить вообще так себе идея, лучше лепить MANDATORY
- если мы заставляем "клиента" явно объявлять транзакцию, то это начинает довольно сильно влиять на структуру его кода: нужно или часть методов в public выносить (+ еще появляются приседания с проксями) либо какой-то непонятный утиль внедрять - на мой взгляд это слишком много мороки для большинства случаев

какой из двоих Стас прав?

Эт да.. Хотя как ты выше писал если кто-то отловит исключение внутри @Transactional и продолжит работу с сессией, то снова отхватит тот же optimistic exception. Так что как будто бы не супер страшно, но согласен что баги возможны в таком раскладе.
Андрей Панфиловболее того, мы таким образом вытаскиваем кишки нашего DAO на "клиента"Про кишки не понял.
Ну вот лично я знаю каким образом спринг забороть чтобы транзакции не фейлились, при этом еще могу найти способ компенсировать OptimisticLockException - там не то что бы сложно, но вот DAO - это абстракция, естественно она будет забарываться (причем успешно) за счет знаний конкретной реализации - вот и получилось что верхний слой знает про работу нижнего, что в свою очередь означает что абстракция у нас с дырками (ну просто представьте себе что DAO делает один отдел/компания, а бизнес-логику - другой)

Ну а иначе управление транзакциями становится каким-то очень скрытным и неявным процессом - не каждый разработчик поймет что с ними происходит. И у меня возникала бы постоянно паранойя - это специально сделали или просто забыли про транзакции. А утиль - очень простое и явное решение в таких случаях.)

У вас ожидания слишком уж тенденциозные, действительность она совсем другая:
- о том что @Transactional работает только через прокси знают только те, кто с этим сталкивался (чинил баги или тыкнули носом на ревью), разработчик средней руки о таком поведении ни сном ни духом, т.е. предоставляемое API уже само по себе так себе
- API действительно работает через *опу - вот у меня есть вполне себе законные основания полагать, что там где я начал транзакцию, там я и должен принимать решение о фиксации или откате, однако, текущее API исходит из того, что ничерта непонятно, поэтому давайте будем защищаться от "говнокода"

И вот дальше вы пытаетесь размазать ответственность за кривой API между всеми (давайте в DAO не лепить @Transactional), а мое мнение заключается в том, что пусть хотя бы один слой работает правильно, а тот, кто делает неправильно, пусть с этим и разбирается.