Поведение по умолчанию методов @Transactional, которые генерируют исключения, довольно широко обсуждается (например, см. результаты поиска здесь ) и четко документировано в Javadoc org.springframework.transaction.interceptor.DefaultTransactionAttribute .По сути, исключения и ошибки времени выполнения вызывают откат, а проверенные исключения - нет.
Тем не менее, с ростом использования Kotlin я думаю, что существует повышенная опасность довольно катастрофических проблем, закрадывающихся в незнакомый код, и мне интересно,следует рассмотреть возможность изменения поведения DefaultTransactionAttribute, чтобы оно соответствовало поведению TransactionTemplate , который выполняет откат при проверенных исключениях.
Проблема, которую я обнаружил, была в куске кодагде метод @Transactional Kotlin косвенно вызывал метод Java, который объявлял проверенное исключение - исключение, которое на самом деле происходило очень и очень редко.
Цепочка вызовов метода Kotlin, приводящая к методу Java, не перехватила и не обработалас проверенным исключением в любой момент, и, конечно, компилятор совершенно доволен этим.Несомненно, автор кода или рецензент должны были заметить упущение, но в действительности это та проблема, которую довольно легко можно пропустить.Если он пропущен, результат действительно очень плохой - в моем случае транзакция была зафиксирована, даже если в момент, когда все взорвалось, была создана только половина ожидаемых объектов, а фактическое исключение было проглочено в TransactionAspectSupport, поэтому нигде не было видно.Я обнаружил проблему только потому, что (к счастью) в последующем фрагменте кода было нарушение ограничения целостности.
Является ли это тем случаем, когда воздействие достаточно велико, чтобы код платформы защищал разработчиков от самих себя?В Java очень трудно случайно совершить эту ошибку, но в Котлине это совсем другое дело.