natanabrahamjrтогда с этой аннотацией тупо падает вообще.
Так тупо падает, что ни сообщения об ошибке ни стэка? А есть понимание что JDBC он однопоточный? Одна транзакция на разные потоки может не работать.

natanabrahamjrждбс однопоточный... и что?
Не, ничего. Всё нормально. Ты, походу, сам в курсе всего. Исключения хотя бы читать научись, чтобы источник его найти, а не самое верхнее сообщение об ошибке.

natanabrahamjrв общем, судя по мануалу, работать должно как есть. но не работает.
Нет никаких "должно" - есть конкретные требования - один поток, одна транзакция. Не нужно пытаться продолжить текущую транзакцию в Async методе.
Нет никаких "не работает". Есть конкретные исключения, сообщения об ошибках или не верное диагностическое состояние. Что именно происходит? Исключение? В какой момент? stacktrace мы так и не увидим. Корневое сообщение об ошибке тоже, похоже, тайна покрытая мраком.

natanabrahamjrБлакович, так я и не пытался "продлить" транзакцию.

А мне откуда знать. Я кода кроме как Transaction Template не видел. Где код, который создаёт новую транзакцию.

natanabrahamjr я просто хотел иметь транзакцию, дабы был доступ к лейзи полям.

OMFG. То есть мы ещё и транзакцию от сессии отличить не можем? Это как бы совершенно разные вещи. То что у них одинаковая область действия ещё не делает их одним и тем же.

natanabrahamjrпусть будет новая транзакция - ни разу не проблема.

Блин.
В чем конкретно задача? Мы на второй странице, вдруг, выяснили что нужна не транзакция а сессия. Что вообще значит "пусть будет"? Вы понятия не имеете как должна работать программа?

questionerА как это требование налазит на вложенные транзакции кстати?
То есть поможет OP propagation Requires_New ?
Это не вложеная транзакция, а новая.

natanabrahamjrдабы был доступ к лейзи полям
То что JDBC не многопоточный повторять бесполезно? Всё равно будет проигнорировано?

natanabrahamjrЯ вас понимаю, и про ждбс и про транзакции и про всё остальное, что там в потрохах происходит.
Вы себе льстите.

natanabrahamjrа) поле не лейзи, а игер.
б) мы запрашиваем лейзи поля в методе, помеченном транзакшнл.

--- как бы на этом ВСЁ.

Потому что нихера не ВСЁ. Потому что Session aka EntityManager aka Unit of Work это не транзакция. Потому что ленивые свойства грузятся из сессии, а не транзакции. И грузятся они через JDBC, поэтому сессию нет смысла шарить между потоками.
Да, в спринге, по-умолчанию, сессия ORM и транзакция связаны друг с другом. Но это совершенно не повод их мешать в кучу.


natanabrahamjrв детали вдаваться смысл есть только из академического интереса
Ну-да, ну-да. Это сродни фразе "SQL знать не нужно, Hibernate сам всё сделает".

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

Теперь к решению.
Попробуйте получить текущую сессию и вызвать merge на объекте. После этого должны заработать ленивые свойства.
Вот тут пишут что @Async и @Transactional на одном методе уже починили.
Значит дело за малым - "переподключить" ленивую сущность к новой сессии.

questionerСорри, новая.
Ну и видимо должно помочь, если если это допускают требования
Да, должно и по-умолчанию работать с REQUIRE, потому как в новом потоке (@Async) всё равно нет старой транзакции, поэтому будет создана новая.

natanabrahamjrфулстэктрейс в атаче.
Корневое и самое любопытное исключение
аттачorg.postgresql.util.PSQLException: ERROR: relation "donations" does not exist
А точно ленивые свойства грузятся без @Async? Либо таки дело не в Async, либо новый поток вообще не в ту базу законектился, что очень странно.

natanabrahamjrа теперь... если я в блоке конфигурации создаю ЯВНО езекутор, вернее, бин екзекутора, возвращающий тредпултаскекзекутор - то вуаля, всё замечательно пашет. даже асинку говорить не надо какой бин цеплять для асинхронного исполнения.
Вот это совсем странно. Spring же там свой экзекутор использует, если его не указать явно. Какая между ними принципиальная разница?

А что за поток такой ?
аттач[pool-27-thread-1] o.h.e.j.b.i.AbstractBatchImpl HHH000010: On release of batch it still contained JDBC statements
Может там, таки транзакция или сессия умудрилась зашарится между потоками, потому как
ERROR: relation does not exist
происходит далее как в асинхронных методах SimpleAsyncTaskExecutor-XX, так и в основном методе из web.