언젠간 도착하겠지

(이전 글에서 이어지는 내용) 더티 체킹으로 인한 업데이트 오류 트러블 슈팅문제의 발단"오늘 예약 마감됐어요. 하지만 빈자리는 있어요."MSA 프로젝트로 '대규모 트래픽 문제를 해결하는 호텔 예약 서비스'를 개발하였다. 300개의 예약이 가능할때, 300명이 동시에 예약을disnotacat.tistory.com 이전 포스팅에서 JPQL을 활용하여 벌크 업데이트를 진행하였다. 코드를 수정하면 반드시 조회에서 문제가 발생할 것이라고 예상하였다.하지만, 서비스에서는 아무런 문제가 발생하지 않았다.    왜 내 코드는 정상 동작했을까?  예상했던 문제는 무엇인가?JPQL 을 활용한 벌크 업데이트는 영속성 컨텍스트에 반영되지 않는다. 업데이트 요청 후 다시 영속성 컨텍스트를 조회하였을 때, 업데이트되지 않은 정보..

문제의 발단"오늘 예약 마감됐어요. 하지만 빈자리는 있어요."MSA 프로젝트로 '대규모 트래픽 문제를 해결하는 호텔 예약 서비스'를 개발하였다. 300개의 예약이 가능할 때, 300명이 동시에 예약을 할 경우,모두 예약 성공을 응답받지만 데이터베이스에는 기록이 되지 않는 이슈가 발생했다.  300명이 동시에 예약을 하면 성공적으로 예약된 데이터를 반환받았다.하지만 막상 예약된 객실 수를 보면 아래와 같이 예상할 수 없는 숫자가 저장되었다.  Lock 에서 발생한 문제라고 생각했지만 결과적으로,원인은 더티체킹으로 업데이트를 처리하였기 때문에 발생했다.  원인왜? JPA 를 쓰면 더티체킹으로 업데이트하지 않나? RoomTypeInventoryEntity 는  예약된 객실 수 정보를 보관하는 앤티티다.Inve..

무수히 많은 데이터를 전부 조회하기 위해서는 1차적으로 필요한 만큼 화면에 뿌리기 위해 페이징이 필요하다. 추가로 검색 조건, 조건 정렬 등의 검색 기능이 포함될 수 있다.Page 인터페이스만 알고 있던 중 QueryDSL 함께 활용한 Search 구현 방법을 알게 되었다.Search 를 구현하며 겪은 트러블 슈팅을 중심으로 구현 방법을 정리해 보았다.짚고 넘어가기 JPA 의 Page@GetMapping("/search")public Page getAllUsers( @RequestParam(required = false, defaultValue = "10") int size, @RequestParam(required = false, defaultValue = "10") int page) { ..