Comments 9
а как же вызов метода с аннотацией "Transactional" в том же классе?
Заголовок оригинальной статьи не содержит слова "критический", потому что ничего критического в этих ошибках нет. А у вас мало того, что кликбейтная формулировка, так ещё и фраза построена так, будто ошибка в самом Spring Boot, а не в приложениях на его основе.
Статья хорошая, только одно но. Это не ошибки, а халтура.
Для каждой транзакции выполняется дополнительный запрос ...
Разве может выполниться отдельный запрос без открытой транзакции?
Включите spring.jpa.show-sql=true и spring.jpa.properties.hibernate.format_sql=true в development
Лучше по другому
The best way to log SQL statements with Spring Boot
https://vladmihalcea.com/log-sql-spring-boot/
А при чем тут SpringBoot? Ну кроме "советов" именно по его особенностям.
Да и вообще, случайно надерганный набор "проблем" без контекста.
Типа:
Теперь Hibernate выполняет один запрос с JOIN:
Выдернутый без контекста, это пример != хорошая практика. Если, например, только в 1% случаев нужно доп данные, то всегда их догружать через JOIN не лучший вариант.
Правильный подход
DataAccessException e) {
..
throw new ServiceException("База данных временно недоступна", e);
Ну ну. В тех случаях, когда API торчит наружу, все это становится очень хорошими подсказками для хакера.
И нормально работающий СИБ и/или внешний аудитор на это пальцем потыкает "незяя".
Так что нет. Изначальный вариант с неопределенным HTPP 500 (типично любой "не определенный" exception -> мапится на 500) + "something went wrong" = лучший вариант для сервиса торчащего во внешний мир. Причем даже не на уровне конкретного места. А на уровне мапинга Exception на HTTP ответ (@RestControllerAdvice в идеологии SpringBoot)
В общем, статья ради статьи.
3 ошибки при работе со Spring Boot, которые просачиваются в прод (и как их исправить)