본문 바로가기

Develop

 (317)
[JPA] JPA 트랜잭션 사용 스프링 데이터 JPA가 제공하는 Repository의 모든 메소드에는 기본적으로 트랜잭션이 적용되어 있다. 클래스,인터페이스,메소드에 사용가능, 메소드에 가장가까운 애노테이션이 우선순위가 높다. 기본적으로 Transactional(readOnly = true) 는 아무런 설정을 하지 않는 메서드에 적용된다. Transcational 옵션 -timeout설정 가능 -readOnly 인지 나타내는 flag 이값을 주면서 optimization 성능 최적화를 해줄 수 있는 여지가 생김 -가급적, 데이터 변경 할 일없으면, readOnly true로 해주는게 좋다. -> JPA에서 해당 readOnly로하게되면, 세션 플러시 모드가 매뉴얼로 설정이 되고 해당 설정이 되면 강제로 플러시를 하지 않는 이상 플러시를..
[JPA]QueryDSL 사용이유, 정의 QueryDSL : JPQL 빌더로 동적 쿼리를 메소드로 구조화하여, 관리할 수 있도록 돕는 쿼리빌더 라이브러리이다. 사용 이유 : 문법이 sql문과 거의 유사, 문법 검색이 가능하다, string으로 쿼리를 작성하지 않아서, compile 시점에 에러를 잡아준다. 검색 조건 등 복잡한 동적 쿼리를 가능하게 해준다. 정리 QueryDsl 장점 - IDE 코드 자동완성 기능을 사용할수 있어 빠른개발이 가능하다. -문법적으로 잘못된 쿼리를 거의 허용하지 않는다. -도메인 타입과, 프로퍼티를 편리하게 참조할 수 있다. - 도메인 타입의 리펙토링 작업이 수월하다. 해당 관련 QueryDsl은 자세한 포스트를 통해 직접 실습을 해봐야겠다.
[JPA] ID를 Long으로 하는 이유 우선 Primitive type은 null을 허용하지 않고, wrapper class는 null을 허용한다. 만약 Long으로 하지않고, long으로 한다고 가정하면 값이 0인 경우 없는건지, 아니면 id 자체가 0인지를 알수 없다. Wrapper타입인 Long이나 Integer를 쓰면, id가 없는 경우, 확실히 null로 id가 없다는 것을 보장할 수 있다. 추가로, 이 id가 없다는 것으로 신규 객체인지 기존 객체인지 확인도 가능하다
[JPA] save, saveall의 성능차이 save와, saveall의 동작 차이 -save -기존 트랜잭션이 존재하는경우 save를 호출하는 경우, 트랜잭션이 존재 경우, 기존 트랜잭션에 참여하게 된다. 기존 트랜잭션에 참여하지만, spring의 프록시 로직을 타게된다. -기존 트랜잭션이 없는 경우 생성후 종료된다. -> 리소스 소모가 크다. -saveAll -기존 트랜잭션이 존재하는 경우 기존 트랜잭션에 참여한다. -saveAll->save를 호출하지만, 같은 인스턴스 내에서 호출하기 때문에 프록시 로직을 타지 않는다. save로직이 한건당 프록시 로직을 매번 탈수도있고, saveall로 하게되는 경우 같은 인스턴스 내에서 호출 되기 때문에 건당 프록시 로직을 타지않게 된다. 1000건이라고 가정하면, 프록시 로직을 천번을 매번 타는것과, 한..
[JPA] 패치조인이란 패치조인은 JPQL에서 성능 최적화를 위해서 제공하는 기술이다. 연관된 엔티티나 객체를 한번에 조회해 오는 기능이다. N+1 문제가 발생하는 경우, 발생가능성이 있는 경우, 연관관계를 맺고 있는 다른 엔티티까지 한꺼번에 조인을 사용해서 실제 엔티티의 값을 가져온다. 단 한번의 쿼리로 값을 다 가져오기 떄문에, N+1 문제 발생 가능성을 차단할 수 있다. 일반 조인 : 조인을 대상으로 한 테이블의 값을 가지고 조회하는 대상의 테이블의 값을 가져올때 사용하는 것이 다이다. 즉, 대상 엔티티의 값을 가져오는 기준으로만 사용하고, 별도 조인 대상의 엔티티의 값을 가져오지는 않는다 패치 조인 : 조인 대상 엔티티의 값을 함께 가져온다. sql에서의 distinct는, 중복을 제거한다. 즉 특정 컬럼에 대한 중복을..
[JPA] N+1 문제란 N+1 문제는, JPA의 Entity 조회시, Query 내부에 존재하는 다른 연관관계에 접근할 때 또 다시 한번 쿼리가 발생하는 비효율적인 상황을 일컫는 말입니다. 1. 즉시 로딩 변경후, findAll로 조회하는 경우 OneToMany의 기본 로딩전략은 LAZY이지만, 해당 전략을 즉시로딩으로 변경하고 findAll을 하게되면, 하위 연관관계에 대한 전부를 조회해야하기 때문에 N+1이 발생할 수 있다. ex. Post와 comment인 경우 Post를 조회하고, 하위의 comment를 전부 조회한다. 즉, Post의 개수대로, comment를 조회하는 쿼리가 추가로 나간다. * 해결 방법 지연로딩으로 변경 2.지연 로딩 변경 + Loop 조회 findAll로 가져올때는 N+1 발생하지 않는다(지연 로..
[JPA] JPA 동작과정 (조회,저장, 수정) JPA 동작 과정 -저장 과정 JPA 의 경우 트랜잭션 실행 단위 안에서 동작한다. 엔티티를 조회,저장,수정등 작업이 일어나면 SQL문이 DB에 적용되는 것이 아니라 쓰기지연 SQL저장소라는 곳에 SQL이 쌓이게 된다. 이렇게 생성된 SQL문들은 트랜잭션 플러시가 일어나는 경우 DB에 쿼리를 보내게 된다. -수정 과정 수정할 엔티티를 찾는다. 1차 캐시에 올라가고 영속상태가 된다. 영속성 컨텍스트가 관리하는 상태가 된다. JPA는 데이터 베이스 트랜잭션 커밋 시점에 변경감지 기능을 사용하게 된다. 1차 캐시에 등록된 상태의 스냅샷과 해당 엔티티를 비교해서 변경내역을 확인하고 (변경감지, dirty checking) update 쿼리를 쓰기지연 저장소에 저장하고 트랜잭션이 끝나기 전에 해당 쿼리를 날리고 ..
[JPA] 영속성 컨텍스트란? 영속성 컨텍스트란 엔티티를 영구 저장하는 환경이라는 뜻이다. 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다. 엔티티 매니저를 통해 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다. -특징 엔티티 매니저를 생성할때 하나 만들어진다. 엔티티 매니저를 통해서 영속성 컨텍스트에 접근하고 관리할 수 있다. -이점 1차 캐시 영속성 컨텍스트에는 1차 캐시가 존재한다. 엔티티를 영속성 컨택스트에 저장하는 순간 1차캐시에 객체가 key,value값으로 저장된다. 엔티티 매니저가 값 을 조회할때 엔티티가 존재하는 경우 DB조회를 하지 않고, 바로 리턴해준다. 동일성 보장 영속성 컨택스트에서 꺼내온 객체는 동일성이 보장된다. 같은 엔티티를..

티스토리툴바