Jinnie devlog

커머스 시스템의 주문 로직에 쿠폰 기능을 추가하면서, 주문 과정에 필요한 트랜잭션이 점점 많아졌다. 그동안은 거의 모든 서비스 클래스에 @Transactional을 붙여 사용했고, 특별한 문제는 없었다.그런데 찾아보니 무분별한 트랜잭션 사용은 성능 저하와 의도치 않은 트랜잭션 경계를 만들 수 있다는 사실을 알게 됐다.그래서 “가능한 한 @Transactional을 빼보자”는 마음으로 무작정 제거 후 테스트를 돌렸다가, 두 번의 힘든 경험을 했다.첫번 째 경우 - 좋아요 기능의 TOCTOU(체크-사용 사이 레이스)public LikeInfo like(LikeCommand.Create likeCommand) { final LikeEntity likeEntity = LikeEntity.of(likeCom..

N+1 문제란, 연관 관계에서 발생하는 이슈로 연관 관계가 설정된 엔티티를 조회할 경우에 조회된 데이터 갯수(n) 만큼 연관관계의 조회 쿼리가 추가로 발생하여 데이터를 읽어오게 된다. 이를 N+1 문제라고 한다. N+1이 발생하는 이유는? jpaRepository에 정의한 인터페이스 메서드를 실행하면 JPA는 메서드 이름을 분석해서 JPQL을 생성하여 실행하게 된다. JPQL은 SQL을 추상화한 객체지향 쿼리 언어로서 특정 SQL에 종속되지 않고 엔티티 객체와 필드 이름을 가지고 쿼리를 한다. 그렇기 때문에 JPQL은 findAll()이란 메소드를 수행하였을 때 해당 엔티티를 조회하는 select * from Owner 쿼리만 실행하게 되는것이다. JPQL 입장에서는 연관관계 데이터를 무시하고 해당 엔티..

연관관계가 있는 엔티티를 조회할 경우 지연 로딩으로 설정되어 있으면 연관관계에서 종속된 엔티티는 쿼리 실행 시 select 되지 않고 proxy 객체를 만들어 엔티티가 적용시킨다. 그 후 proxy 객체를 호출할 때마다 그때그때 select 쿼리가 실행된다. 위와 같은 연관관계가 지연로딩으로 되어있을 경우 fetch 조인을 사용하여 여러 번의 쿼리를 한번에 해결할 수 있다. @EntityGraph는 Data JPA 에서 fetch 조인을 어노테이션으로 사용할 수 있도록 만들어 준 기능이다. 엔티티들은 서로 연관되어 있는 관계가 보통이며 이 관계는 그래프로 표현이 가능하다. EntityGraph는 JPA가 어떤 엔티티를 불러올 때 이 엔티티와 관계된 엔티티를 불러올 것인지에 대한 정보를 제공한다. Fetc..

@ManyToMany 사용을 되도록 피해야 한다고 배웠다. 그 이유는, 개발하다 보면 연결 테이블이 단순히 연결만 하고 끝나지 않는다. 조인 테이블 자체에 주문 시간, 수량 같은 추가 데이터가 많이 들어갈 수 있다. 하지만, 매핑 정보만 넣는 것이 가능하고, 추가 정보를 넣는 것 자체가 불가능하다. 그리고 중간 테이블이 숨겨져 있기 때문에 예상하지 못하는 쿼리들이 나간다. 이러한 문제점들 때문에 실무에서는 사용하면 안된다고 한다. 해결 방법으로는, 연결 테이블용 엔티티를 추가한다. 사실상 연결 테이블을 엔티티로 승격시킨다. 그리고 @ManyToMany를 각각 일대다, 다대일로 관계를 맺어준다. JPA가 만들어주는 숨겨진 매핑테이블의 존재를 밖으로 꺼내는 것이다. 등이 있다. 나는 그럼에도 다대다 관계를 ..