일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- 우아한테크코스
- MSA
- yml
- CircuitBreaker
- Docker
- HTTP
- 스프링 부트
- 스프링부트
- JPA
- 코드리뷰
- Level2
- 세션
- 우테코
- Spring Batch
- mock
- 의존성
- Paging
- 트랜잭션
- 레벨2
- 프로그래머스
- JUnit5
- AWS
- 백준
- 우아한세미나
- AOP
- 미션
- 프리코스
- 자바
- 서블릿
- REDIS
Archives
- Today
- Total
목록배타락 (1)
늘
JPA(ORM)의 영속성컨텍스트에서 더티체킹이 좋은걸까? Lock을 통해 해결해보자(MVCC를 지원하는 DB를 사용할 때)
해당 글은 innodb에서 lock이 어떻게 동작하는지 어느 정도 알고 있는 상태에서 읽으면 좋을 것 같습니다! 제목에 JPA가 들어가서 주제가 JPA에 한정적으로 보일수 있겠다. 하지만 실제 해당 이슈는 JPA 뿐만 아니라 모든 곳에서 발생이 가능하다. 하지만 JPA에서는 dirty checking이라는 기능을 지원해주므로 더욱 조심해야 한다고 생각해서 제목으로 지어봤다. 본론으로 들어가자면 해당 상황이 위험한 이유는 lock과 관련이 있다. 그중에서 Lost Update 문제이다. (저희 서비스는 JPA와 MVCC를 지원하는 Mysql Innodb를 사용합니다.) QA를 진행하다 다른 팀에서 데드락이슈를 맞이했다. 우리 팀은 괜찮을까 테스트해보다가 다른 이슈를 맞이했다. 바로 동시성 이슈였는데 해당 ..
우아한테크코스 4기/프로젝트
2022. 10. 22. 18:20