이전 프로젝트는 현재 담당하고 있는 것 보다 규모가 훨씬 커서 테이블의 종류가 많았다. 그래서 다양한 테이블에 insert하는 매서드의 경우 중간에 오류가 발생하는 경우를 대비해 별도의 Exception을 정의하고 데이터 무결성을 위해서 rollback 처리를 반드시 해줬어야 했다. 그런데 현재 프로젝트로 넘어와서 코드를 확인해보니, @Transational 어노테이션만 붙이고, rollback은 따로 처리하지 않고 있었다. 지금 생각해보면 이유라기보다는 개발자의 미숙에 가까운게, 해당 프로젝트는 단 하나의 CustomException이 없었다. Checked Exception이 없기 때문에 굳이 rollbackfor를 정의할 필요가 없다는 생각이었을까? 정말 안전할지 알아보자. Transcational..
JPA를 사용해 DB insert를 하던 중 뜬금없이 아래와 같은 에러가 났다. java.sql.SQLException: The MySQL server is running with the --read-only option so it cannot execute this statement 흠 DB가 어떤 이유에서인지 read-only 설정이 되어 있군. 인프라 개발자에게 연락해야지. 라고 끝났으면 좋았겠지만, 인프라는 DB 설정을 변경한게 없다고 한다. 웃긴건, 같은 프로젝트의 다른 서비스 내에서의 DB insert는 정상적으로 수행되고 있다는 점이다. 다른 서비스와 차이점을 뜯어보던 중 @Transactional 이 빠져 있는걸 확인했다. @Transactional 어노테이션을 붙이니까 정상 동작했다. 그..
- Total
- Today
- Yesterday
- lambda
- java
- OpenFeign
- terraform
- 스프링부트
- Spring
- S3
- Elastic cloud
- JWT
- GIT
- Log
- 티스토리챌린지
- 오블완
- serverless
- openAI API
- docker
- EKS
- elasticsearch
- springboot
- AWS
- OpenAI
- MySQL
- AOP
- AWS EC2
- 후쿠오카
- ChatGPT
- CloudFront
- Kotlin
- 람다
- cache
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |