Atum1,

ща насоветуют дичи... все уже давно изобретено:

забыл никЕсть куда деваться. Как раз вот статья вышла хорошая, но это нужно иметь кое-какие знания о ФП чтобы понять.
Тыц Чет там какой-то обман кмк.




При этом у автора претензия:

авторLack of precision. Without looking at the code in its entirety, we can’t be sure where transactions exactly begin and commit. An @Transactional method might define the transaction boundary, or might take part in a broader transaction. It’s not possible to differentiate between these two scenarios.

Вот как смотря в код sendEmail я могу понять в транзакции он будет выполняться или нет?

забыл никАндрей ПанфиловAtum1,

ща насоветуют дичи... все уже давно изобретено:




Которое также легко удаляется пьяным сеньорома зачем удалять? У нас же нет контракта вида "где-то должны стоять аннотации", а есть контракт вида "этот метод требует выполнения в транзакции", соответственно assert прекрасно этот контракт обеспечивает и никакие дополнительные тесты писать не нужно, достаточно то что есть (если конечно есть) запускать с -ea

забыл никНикак, но в этом и весь цимус, что вам это и не надо.
Чет какая-то жесть...
- проблема: очень печально что мы не видим где транзакция начинается (в endpoint транзакции начинаются по канону)
- решение: берем скалу, теперь мы все равно не знаем где начинается транзакция, но проблемы уже нет - теперь у нас жопа в другом месте

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

забыл никАндрей ПанфиловЧет какая-то жесть...
- проблема: очень печально что мы не видим где транзакция начинается (в endpoint транзакции начинаются по канону)
- решение: берем скалу, теперь мы все равно не знаем где начинается транзакция, но проблемы уже нет - теперь у нас жопа в другом месте


Да с чего вдруг? На самом деле идея простая, но не сразу дается, когда переходишь со спринга(сам так тупил)




В целом - sendEmail, insertUser - маленькие кусочки реюзаемой логики, никаких cross-cutting concerns.
В Контроллере ты компонуешь эти кусочки как вздумается, и когда тебе нужен результат(а не дескрипшен твоего действия) - передаешь туда транзактор, обычно это как раз в эндпоинтах контроллера.
В данном случае (исходим из обсуждаемого примера) получается так:
чтобы дернуть MailService мне его нужно его заврапить в ConnectionIO (там в статье пишут IO.to[ConnectionIO]), поэтому везде по приведенному коду мне нужно расставить этот .to[ConnectionIO] "чтобы скомпилировалось", дальше проходит время, я выхожу из запоя и принимаю решение что почту мне нафиг посылать не нужно прямо вот сейчас, а можно и через некоторое время, поэтому я иду и меняю реализацию MailService чтобы оно писало в БД вместо отправки почты, а потом бегаю по всему коду и убираю .to[ConnectionIO] потому что теперь не компилируется - какое-то сомнительное удовольствие кмк.

забыл никВыполнить кусок кода вне транзакции не получится в любом случае. Если нужна параллельная - ну вызывай в другом потоке, транзактор тредсейф. А вообще звучит как "а ваша пила умеет сталь пилить?", хотелки какие-то непонятные, хотя прикол в том, что даже их без проблем можно реализоватьЗдрасьте, требования как требования (ну вот спринг же умеет, а он ориентирован на JSR 907, который не последние люди в мире жавы разрабатывали), да и вызов в другом потоке и открытие новой транзакции из текущего - это два совершенно разных паттерна.