JPA

낙관적 락 @Version을 사용 트랜잭션을 커밋하는 시점에 충돌을 알 수 있음 비관적 락 선점 잠금 데이터베이스 트랜잭션 락 메커니즘에 의존하는 방식 SQL 쿼리에 select for update 구문을 사용하면서 시작 버전 정보는 사용하지 않음 JPA 락 옵션 낙관적 락 OPTIMISTIC 낙관적 락을 사용한다. 낙관적 락 OPTIMISTIC_FORCE_INCREMENT 낙관적 락 + 버전정보를 강제로 증가한다. 비관적 락 PESSIMISTIC_READ 비관적 락, 읽기 락을 사용한다. (공유 잠금) 비관적 락 PESSIMISTIC_WRITE 비관적 락, 쓰기 락을 사용한다.(배타적 잠금) 비관적 락 PESSIMISTIC_FORCE_INCREMENT 비관적 락 + 버전 정보를 강제로 증가한다. 기타 ..

변경감지 변경감지는 트랜잭션 커밋시 영속화된 Entity에서 가지고 있었던 최초 정보(스냅샷)와 바뀐 Entity 정보를 비교해서 바뀐 부분을 update 해주는기능 1. 클라이언트에서 식별자를 포함한 데이터를 넘김 2. 식별자(id)를 통해서 DB에서 데이터 조회 후, 조회된 데이터를 영속화 . 클라이언트에서 넘어온 값들을 토대로 기존의 데이터를 새로운 데이터로 변경 : 변경점 발생 4. 트랜잭션 커밋 5. JPA에서 변경점들을 확인하고 변경해야할 것에 맞게 DB 쿼리를 실행 : 변경 감지 (Dirty checking) 변경감지 조건 변경하려는 Entity가 영속 상태여야함 (영속성 컨텍스트 안에 관리되는 상태) 트랜잭션 안에 묶여 있어야함 트랜잭션이 제대로 커밋되어야함 (그래야 flush가 작동하기 ..

1. 즉시로딩jpql을 우선적으로 select하기 때문에 즉시로딩을 이후에 보고 또다른 쿼리가 날아가 N+12. 지연로딩지연로딩된 값을 select할 때 따로 쿼리가 날아가 N+13. Fetch Join지연로딩의 해결책사용될 때 확정된 값을 한번에 join에서 select해서 가져옴Pagination이나 2개 이상의 collection join에서 문제가 발생4. EntityGraphHibernate의 Jpql 구문에서의 fetch는 존재하지는 않지만 기존과 마찬가지로 fetch join을 통해 바로 조회할 수 있음@Repositorypublic interface PersonRepository extends JpaRepository, JpaSpecificationExecutor { @NotN..

사용 이유 jpa nativeQuery로 쿼리 조회를 하다가 다중 필터를 사용하게 되면서, where절을 유동적으로 사용하기위해 사용 // 설문조사 리스트 조회 @Query(value = "SELECT sc.content, s.* " + "FROM survey s left join survey_category sc on sc.sur_cat_id = s.category_id " + "WHERE 1=1 " + "and s.status = 'I' " + "and s.is_private = 'N' " "and s.category_id = :categoryId " , nativeQuery = true) Page findByCategoryIdAndStatus(@Param("categoryId") int catego..