개발놀이터

이번 포스팅에선 트랜잭션 전파에 대해서 알아보도록 하겠습니다. 사실 트랜잭션 전파에 대해서는 어느정도 알고 있는 부분이 있었는데 제가 아는 수준은 "트랜잭션 전파를 이용하면 데이터 정합성을 유지할 수 있고 그 단계에는 일곱가지 (REQUIRED 외 6개) 가 있다." 그리고 각각의 전파 단계에 대해서 학습을 했는데요. 그러다 오랜만에 인프런에 들어갔는데 사놓고 안들은 강의가 있었습니다. 김영한님의 DB 접근기술 2탄이었습니다. 이걸 왜 안봤지? 싶어서 봤는데 정말 흥미로운 내용이 있었습니다. 왜 트랜잭션을 전파할 수 밖에 없었는지, 전파 도중 롤백이 일어나면 어떻게 처리하게 되는지에 대한 내용을 상세하게 알려주셨습니다. (역시 영한님!) 이번 포스팅에선 그 내용에 대해서 제 언어로 정리하기 위해 적는 포..

이번 포스팅에선 JPA에서 엔티티의 생명주기에 대해서 알아보도록 하겠습니다. 스프링의 빈 생명주기를 공부해 보신 분들이라면 JPA의 엔티티 생명주기라는 말을 들으실 때 대충 감이 잡히실겁니다. 엔티티의 생명주기란 엔티티를 사용할 수 있는 다양한 상태라는 것을 말이죠. 스프링 빈 생명주기에 객체 생성, 의존 설정, 초기화, 사용, 소멸의 생명 주기를 가지고 있다면 JPA의 엔티티는 Trasient (비영속), Managed (영속), Detached (준영속), Removed (삭제) 상태가 있습니다. 한번 자세히 알아보죠. JPA 엔티티 생명주기 New / Transient (비영속) 엔티티 객체가 생성된 상태를 말합니다. 이 상태를 New 혹은 Transient 상태라고 합니다. 이 상태는 객체가 아직..

이번 포스팅에선 JPA의 복합 기본 키에 대해서 알아보겠습니다. 사실 이 내용을 공부하면서 이게 대체 왜 필요하지..? 싶은 내용이었습니다. 도저히 실제 애플리케이션에서 사용할 것 같지 않은 개념이라 조금 당황했지만 이것도 엄연히 JPA의 스펙 중 하나이기 때문에 놓치고 싶지 않았습니다. 한번 어떤 내용인지 알아보죠! JPA 복합 기본 키 우선 복합 기본 키라는게 어떤 것인지부터 알아야겠습니다. 복합 기본 키 혹은 복합 키로 잘 알려진 영어로 Composite Primary Key는 컬럼들이 한 행이 보장되는 유니크함을 결합될 때 테이블 안에서 각각의 행들이 유니크하게 식별되는 두개 이상의 키입니다. 이건 왜 사용할까요? 우리가 JPA를 사용할 때를 생각해볼 필요가 있습니다. 만약 이름이 홍길동인 사람을..

이번 포스팅에서는 JPA의 2차 캐시에 대해서 알아보도록 하겠습니다. JPA에서 우리가 익숙한 것은 1차 캐시입니다. 보통 영속성 컨텍스트로 많이 알려진 1차 캐시는 JPA가 동작하면서 필요한 데이터들을 모아두는 공간입니다. 보통 1차 캐시는 트랜잭션별로 저장하기 때문에 휘발성이 강한 캐시 저장소입니다. 반면 2차 캐시는 1차 캐시와 다르게 글로벌하게 적용되는 캐시입니다. 애플리케이션마다 적용되는 캐시로서 애플리케이션이 종료될 때까지 유지되는 캐시입니다. 그럼 이제 본격적으로 2차 캐시에 대해서 알아볼까요? 2차 캐시 2차 캐시란 무엇인가? 2차 캐시는 앞서 설명했듯이 애플리케이션 단위의 캐시로 애플리케이션이 종료될 때까지 유지됩니다. 이 말은 멀티 스레드 환경에서도 글로벌하게 사용되는 캐시라고 이해할 ..

이번 포스팅에선 JPA가 어떻게 동시성 문제를 컨트롤하는지에 대해서 포스팅해보겠습니다. 개인적으로 동시성 문제는 애플리케이션에서 일어날 수 있는 가장 최악의 버그라고 생각합니다. 그 이유로는 RuntimeException이 발생하지 않는다. 컴파일러도 모른다. 심각한 장애를 야기한다. (재고가 1개 있는데 3명이 1개씩 주문하면 재고가 0이 되면서 결제 로그가 세개 찍힘) 때문에 이러한 동시성 문제에 대해 개발자가 반응하고 테스트 케이스를 통해 동시성 문제를 잡아내야한다고 생각합니다. 물론 쉽지는 않지만요. JPA에선 이러한 동시성 문제를 해결하기 위해 두 가지 Locking 매커니즘을 제공합니다. 이제 본격적으로 시작해보죠! Locking 매커니즘 JPA는 Locking 매커니즘으로 두 가지를 제공하는..

JPA는 자바 진영에서 사용하는 대표적인 ORM 중 하나입니다. JPA로 인해 자바 개발자들이 데이터베이스 중심에서 객체 중심으로 설계 방식을 전환할 수 있었다고 개인적으로 생각하고 있는데요. 저는 여태껏 JPA를 사용하는데에만 집중을 했습니다. 그래서 JPA가 가진 특징들에 대해서는 등한시 한 느낌이 있습니다. 하지만 제 공부 방식은 항상 써보고 익숙해지면 개념을 공부하는 느낌이었어서 지금이라도 주요 개념들에 대해서 공부해보고자 오랜만에 JPA 카테고리에 글을 썼습니다. 이번 포스팅에선 JPA가 트랜잭션을 관리하는 방법과 JPA에서 제공하는 다양한 기능들에 대해서 소개해드리고자합니다. JPA가 트랜잭션을 관리하는 방법 JPA는 트랜잭션을 프록시를 이용해서 관리합니다. 여기까지는 보통 알고 있는 내용일겁..

스프링 부트가 5.0이 됨에 따라 그런지 모르겠지만 javax.persistence에 있던 EntityManager가 작동하지 않는 상황이 발생했습니다. 이제 EntityManager는 jakarta.persistence로 바뀌게 되었는데 이에따라 querydsl의 설정을 바꿔줘야할 필요가 생겼습니다. 구글링을 해본 결과는 다음과 같습니다. buildscript { ext { queryDslVersion = "5.0.0" } } plugins { id 'java' id 'org.springframework.boot' version '3.1.0' id 'io.spring.dependency-management' version '1.1.0' // querydsl plugin 제거 //id "com.ewerk..

우리는 보통 @Transactional을 많이 사용합니다. 트랜잭션을 wrapping 해주는 역할로서 많이 사용하죠. 이번 포스팅에선 @Transactional이 무엇인지, @Transactional에서 주로 사용하는 옵션인 Propagation, Isolation에 대해서 알아보도록 하겠습니다. @Transactional 우선 @Transactional에 대해서 알아봐야겠죠? @Transactional은 스프링이 만든 AOP중 하나입니다. @Transactional이 붙어있는 메서드에 한해서 트랜잭션의 원자성을 보장해주고 트랜잭션 시작, 커밋, 롤백을 수행해줍니다. @Transactional의 등장으로 트랜잭션 코드와 비즈니스 로직을 분리하여 개발자들은 좀 더 순수한 비즈니스 로직을 구현할 수 있게 되..

본 포스팅에선 N + 1 문제에 대해서 직접적으로 다루지 않습니다. N + 1 문제에 대한 개념적인 내용은 이미 많이 알려져 있기 때문에 다루지 않습니다. 그럼 이번 포스팅에선 무엇을 다룰것이냐 바로 join fetch 와 @EntityGraph에 대해서 알아볼 것입니다. 그리고 알아보면서 둘의 차이점과 각각을 사용할 때 주의 사항도 알아보도록 하겠습니다. 우선 join fetch부터 보겠습니다. join fetch 대표적으로 알려진 N + 1 문제의 해결 방안입니다. 어떻게 사용하는지와 왜 사용하는지에 대해서는 말씀드렸다시피 다루지 않습니다. 대부분은 join fetch로 문제가 해결되기 때문에 만능이라고 생각하시는 분들이 있습니다. 하지만 join fetch도 만능은 아닙니다. Native Query..

데이터를 저장할 때 '생성된 시간 정보'와 '수정된 시간 정보'는 여러모로 많이 사용되고 또 중요합니다. JPA를 사용하면서 @CreatedDate, @LastModifiedDate를 사용하여 생성된 시간 정보, 수정된 시간 정보를 자동으로 저장할 수 있는데요. 사용 방법과 동작 원리에 대해서 한번 알아보도록 하겠습니다. import lombok.Getter; import org.springframework.data.annotation.CreatedDate; import org.springframework.data.annotation.LastModifiedDate; import org.springframework.data.jpa.domain.support.AuditingEntityListener; imp..