Наверное потому что над 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), а мое мнение заключается в том, что пусть хотя бы один слой работает правильно, а тот, кто делает неправильно, пусть с этим и разбирается.

@Transactional это не часть DAO слоя. То что мы где-то ожидаем что у нас всего один вызов DAO и поэтому мы не ставим @Transactional над сервисом - это неправильное определение обязанностей DAO. DAO не имеет права определять границы транзакции, это не часть DAO абстракции. Как в общем-то и обработка оптимистических блокировок - это часть бизнес логики.
Вы пытаетесь рассказать довольно странную историю на мой взгляд. Из вашего рассказа следует примерно следующее:
- вот есть некий слой который в итоге производит манипуляции в БД (тут на самом деле уже странно, поскольку чтобы заставить хибер что-то сделать в БД до вызова flush нужно очень сильно постараться, а если мы вызываем flush явно, то это на самом деле так себе затея, к тому же это касается исключительно ваших проектов, а не вообще всех подряд, я, к примеру, принимал участие в проекте где вызывать flush() считалось западно)
- вы смотрите в код хибера (точнее спринга) и наблюдаете, что при определенном стечении обстоятельств в вашем проекте оно выкинет более-менее понятное исключение, причем нужно подчеркнуть что именно в вашем проекте и на вполне определенных версиях (здесь как в соседнем топике: 22385060 , chpasha считает что нужно следоать жавадоку, а вы его игнорируете), откуда принимаете решение что нужно делать именно так как вы увидели и несете это знание в массы, здесь есть кое-какие проблемы:
-- если DAO - это самостоятельный слой, то никаких предположений относительно того, как его будут вызывать он делать не должен, т.е. вариантов развития событий в нем всего два: принять данность как есть (т.е. использовать @Trsnsactional), либо отвергнуть (@Transactional(MANDATORY)), у него, как самостоятельного слоя, есть вполне определенная задача: всегда работать корректно
-- оба упомянутых варианта всегда работают правильно вне зависимости от того что вы там себе придумали, отличаются они только тем, насколько мы уважаем "клиента" - еще раз повторюсь: заставлять "клиента" приседать с транзакциями на ровном месте - это путь вникуда
- если у вас разработчики не понимают где начинаются бизнес-транзакции, а где заканчиваются, то это проблема исключительно разработчиков и их руководства

чет у меня есть подозрение, что если по уму делать, то "кастомных" исключений получится где-то полста (которые, к слову сказать, уже в JPA присутствуют), если не добрая сотня, но если скроить, то можно сделать исключение "хрен его знает что тут вообще произошло" и обойтись только им

А как иначе писать, если DAO - это абстракция. Если у меня в DAO не хибернейт закрытый спрингом, а что-то другое, что наличие активной транзакции не проверяет, мне нужно в DAO лепить @Transactional или нет? А если у меня в методах DAO несколько взаимодействий с БД, мне нужно лепить @Transactional или нет? А если дело касается только вашего определенного кейса, тогда почему вы несете в массу "знания" что в DAO лепить @Transactional не нужно?