언젠간 도착하겠지

JPA를 사용한다면 열 번, 백번 꼭 들어봤을 단어들이다.즉시로딩과 지연로딩을 제대로 이해하기 위해서 프록시 개념은 필수적이다.즉시로딩(EAGER)의 문제점엔티티들은 서로 복잡한 연관관계를 가지고 있다.여기 "Family" 와 "Cat" 이 1:N 연관관계를 가지고 있다.Cat1의 이름을 출력하고 싶을 뿐인데, Family가 계속 데이터베이스에서 매번 즉시 조회 되면 어떨까?고양이 한 마리 이름 조회에 필요 이상의 메모리를 사용하게 되고 성능적인 이슈가 발생할 수 있다. 지연 로딩(LAZY) 의 본체여기서 지연로딩이 사용된다.Cat을 조회하고 연관된 Family는 나중에 조회한다는 의미로 지연된 로딩이다. 하지만 연관관계가 있다면 Cat 클래스에는 Family 가 필요하다. 객체지향적으로 우리는 cat...

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

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

JPA 를 활용하면 필드 일부를 수정하는 경우 @Transactional 을 함께 사용하여 UPDATE 쿼리를 요청할 수 있다.트랜잭션의 커밋 단위로 데이터베이스가 변경되며, 수정 사항이 있을 때마다 save() 를 할 필요가 없어진다.이때 활용하는 것이 변경감지, 더티 체킹이다. 엔티티 매니저 (Entity Manage)엔티티 매니저는 엔티티를 저장하고, 수정하고, 삭제하고, 조회하는 등 엔티티와 관련된 모든 일을 처리한다.EntityManageFactory 를 활용하여 엔티티 매니저를 생성한다.엔티티 매니저는 엔티티를 영속성 컨텍스트에서 보관하고 관리한다. 영속성 컨텍스트 (Persistence context)직역하면 ‘엔티티를 영구 저장하는 환경’ 이다.영속성 컨텍스트는 논리적인 개념에 가깝고 눈에..

무수히 많은 데이터를 전부 조회하기 위해서는 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) { ..