DevBoi

save와, saveall의 동작 차이 -save -기존 트랜잭션이 존재하는경우 save를 호출하는 경우, 트랜잭션이 존재 경우, 기존 트랜잭션에 참여하게 된다. 기존 트랜잭션에 참여하지만, spring의 프록시 로직을 타게된다. -기존 트랜잭션이 없는 경우 생성후 종료된다. -> 리소스 소모가 크다. -saveAll -기존 트랜잭션이 존재하는 경우 기존 트랜잭션에 참여한다. -saveAll->save를 호출하지만, 같은 인스턴스 내에서 호출하기 때문에 프록시 로직을 타지 않는다. save로직이 한건당 프록시 로직을 매번 탈수도있고, saveall로 하게되는 경우 같은 인스턴스 내에서 호출 되기 때문에 건당 프록시 로직을 타지않게 된다. 1000건이라고 가정하면, 프록시 로직을 천번을 매번 타는것과, 한..

패치조인은 JPQL에서 성능 최적화를 위해서 제공하는 기술이다. 연관된 엔티티나 객체를 한번에 조회해 오는 기능이다. N+1 문제가 발생하는 경우, 발생가능성이 있는 경우, 연관관계를 맺고 있는 다른 엔티티까지 한꺼번에 조인을 사용해서 실제 엔티티의 값을 가져온다. 단 한번의 쿼리로 값을 다 가져오기 떄문에, N+1 문제 발생 가능성을 차단할 수 있다. 일반 조인 : 조인을 대상으로 한 테이블의 값을 가지고 조회하는 대상의 테이블의 값을 가져올때 사용하는 것이 다이다. 즉, 대상 엔티티의 값을 가져오는 기준으로만 사용하고, 별도 조인 대상의 엔티티의 값을 가져오지는 않는다 패치 조인 : 조인 대상 엔티티의 값을 함께 가져온다. sql에서의 distinct는, 중복을 제거한다. 즉 특정 컬럼에 대한 중복을..

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 의 경우 트랜잭션 실행 단위 안에서 동작한다. 엔티티를 조회,저장,수정등 작업이 일어나면 SQL문이 DB에 적용되는 것이 아니라 쓰기지연 SQL저장소라는 곳에 SQL이 쌓이게 된다. 이렇게 생성된 SQL문들은 트랜잭션 플러시가 일어나는 경우 DB에 쿼리를 보내게 된다. -수정 과정 수정할 엔티티를 찾는다. 1차 캐시에 올라가고 영속상태가 된다. 영속성 컨텍스트가 관리하는 상태가 된다. JPA는 데이터 베이스 트랜잭션 커밋 시점에 변경감지 기능을 사용하게 된다. 1차 캐시에 등록된 상태의 스냅샷과 해당 엔티티를 비교해서 변경내역을 확인하고 (변경감지, dirty checking) update 쿼리를 쓰기지연 저장소에 저장하고 트랜잭션이 끝나기 전에 해당 쿼리를 날리고 ..

영속성 컨텍스트란 엔티티를 영구 저장하는 환경이라는 뜻이다. 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다. 엔티티 매니저를 통해 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다. -특징 엔티티 매니저를 생성할때 하나 만들어진다. 엔티티 매니저를 통해서 영속성 컨텍스트에 접근하고 관리할 수 있다. -이점 1차 캐시 영속성 컨텍스트에는 1차 캐시가 존재한다. 엔티티를 영속성 컨택스트에 저장하는 순간 1차캐시에 객체가 key,value값으로 저장된다. 엔티티 매니저가 값 을 조회할때 엔티티가 존재하는 경우 DB조회를 하지 않고, 바로 리턴해준다. 동일성 보장 영속성 컨택스트에서 꺼내온 객체는 동일성이 보장된다. 같은 엔티티를..

엔티티의 생명주기는 4가지가 있다. 1. 비영속 - 영속성 컨텍스트와 전혀관계가 없는 상태 - 객체를 생성만 한 상태 2. 영속상태 - 영속성 컨텍스트에 저장된 상태 - 엔티티가 영속성 컨텍스트에 의해 관리되는 상태 3. 준영속 상태 - 영속성 컨텍스트에 저장되었다가 분리된 상태 - 영속성 컨텍스트에서 지운 상태 - 준영속 상태에서는 영속성 컨텍스트가 제공하는 기능을 사용하지 못한다.(Dirty Checking, Update Query) (이름 변경에 대한 Entity 데이터 변화를 감지한다. 1차 캐시의 snapshot이 다른것을 감지하면, update query 를 날린다.) 4. 삭제 상태 엔티티를 영속성 컨텍스트와 데이터베이스에서 삭제한 상태이다.

1. ORM이란? Object Relational Mapping 의 약자로, 이름 그대로 객체와 관계형 데이터를 매핑하기 위한 기술이다. 객체와 관계형 데이터 베이스는 패러다임의 불일치가 존재할수 밖에없고, 해당 패러다임을 맞추려, 객체지향적 설계를 할수 없다. ORM은 이러한 문제를 해결한다. 2. JPA java persistence APi의 약자로, 자바 ORM 기술에 대한 API 표준 명세이다. 즉, 인터페이스 모음이다 이 인터페이스를 구현한 프레임워크가 하이버네이트이다. JPA는, 애플리케이션과 JDBC 사이에서 동작하며, JPA를 개발자가 사용하면, JPA 내부에서 JDBC API를 사용하여, SQL을 호출하여 DB와 통신한다. 3. 하이버네이트 JPA를 구현한 프레임워크 중 사실상 표준에 가..

더티 체킹때문에, 실시간 성은 굉장히 좋은 효과를 가지지만 bulk 성 연산에는 약한것같다. 그래서 기능은 있다고 한다. 쿼리 한번으로 여러 테이블 로우를 변경한다. 벌크 연산 주의 벌크 연산은 영속성 컨텍스트를 무시하고 디비에 직접 쿼리한다. - 벌크 연산을 먼저 실행한다. - 벌크 연산 수행 후 연속성 컨텍스트 초기화 한다. 해당 주의사항을 했던 이유는 많은 량의 데이터가 변경되기 때문에, 영속성 컨턱스트를 통해 값을 받게 되면 해당 애플리케이션과 실제 디비의 갑이 다르게 될수 있기 때문이다. Spring data jpa 에서는 Modifying하는 어노테이션이 있는데, 이건 영속성 컨텍스트를 한번 clear 시켜주는 것이다.

Named 쿼리는 쿼리에 대한 실제 이름을 붙일수있다. 즉 query id 를 부여할수있다. - 정적 쿼리만 가능 - 어노테이션, XML 에 정의 - 애플리케이션 로딩 시점에 초기화 후 재사용 - 애플리케이션 로딩 시점에 쿼리를 검증 sql로 파싱해서, 캐싱하고있다.

SQL 조인 기능이 아니다. JPQL에서 성능 최적화를 위해서 사용된다. 연관된 엔티티나 컬렉션을 SQL 한번에 함께 조회하는 기능이다. join fetch 명령어를 사용한다. 이런식으로 join fetch를 하게 되면 내부적으로 inner join이 발생되어서, 해당 쿼리는 한번만으로 조회를 전부 해온다. Lazy fetch type이여도, 프록시 엔티티가아닌, 실제 엔티티 값으로 가져온다. (Team도) 컬렉션 타입을 공부해보자 이런식으로 팀의 member들에 대한 리스트를 가지고있다고 가정해보자 팀은 총 2개인데, 팀을 가진 member가 3인 경우? 총 3개가 노출이된다. 응? 팀을 select 했는데, 왜 3개가 되지 이런경우 사용되는게 바로, distinct이다. Team 하위 멤버가 2개이면..