본문 바로가기

728x90
반응형

Spring 정리/Spring JPA

(19)
트랜잭션 전파 전략 7개 트랜잭션 전파 전략 7개 트랜잭션 전파 전략은 총 7가지가 있습니다. REQUIRED, REQUIRES_NEW, NESTED, MANDATORY, NEVER, SUPPORTS, NOT SUPPORTED를 하나씩 알아보겠습니다. REQUIRED 종속 된 트랜잭션은 현재의 트랜잭션을 따라갑니다. 만약에 현재 트랜잭션이 없다면 새로운 트랜잭션을 만듭니다. 트랜잭션 어노테이션의 기본 설정이기도 합니다. 트랜잭션 기본 설정입니다. 기존 트랜잭션 있음 : 기존 트랜잭션에 참여합니다 기존 트랜잭션 없음 : 트랜잭션 없이 진행합니다 REQUIRES_NEW 종속된 트랜잭션은 언제나 새로운 트랜잭션을 만들고 만약에 트랜잭션이 존재한다면 현재 트랜잭션을 잠시 지연시킵니다. 실제 트랜잭션 지연이 모든 트랜잭션 매니저에서 발생..
스프링 트랜잭션 추상화, 동기화 개요 스프링 트랜잭션의 추상화, 동기화를 이해할 수 있다. 트랜잭션 추상화 JDBC를 사용하다가 JPA로 기술을 변경하면 어떻게 될까요? JDBC 종속적인 수많은 코드들을 JPA로 변경해야 합니다. 그러다가 JPA가 또 다른 기술로 변경되면 어떻게 될까요? 해당 기술에 맞춰서 수많은 변경을 해야 합니다. 아래는 트랜잭션을 사용하는 JDBC 코드와 JPA 코드 비교입니다. 라이브러리가 완전히 바뀝니다. //JDBC public void accountTransfer(String fromId, String toId, int money) throws SQLException { Connection con = dataSource.getConnection(); try { con.setAutoCommit(false);..
스프링 트랜잭션 전파 기본개념 개요 데이터베이스의 트랜잭션 고립 수준에 대해 공부하다가 스프링에서 트랜잭션이 부모와 자식 사이에 전파가 된다는 사실을 알았습니다. 여러 가지 전파 수준이 있는데, 수준에 따라서 어떻게 결과가 달라지는지 궁금해서 테스트를 통해 알아보도록 하겠습니다. 트랜잭션 커밋과 롤백 트랜잭션 시작 시 Hikari에서 커넥션(Connection)을 가져오고 커밋을 하면 Hikari에 커넥션을 반납합니다. 또한, 롤백도 마찬가지로 반영된 내용을 모두 롤백하고 Hikari에 커넥션을 반납합니다. 만약에 아래 코드처럼 첫번째 트랜잭션이 커밋되고, 두번째 트랜잭션이 롤백된다면 트랜잭션 사용은 어떻게 될까요? @Test void double_commit() { log.info("트랜잭션1 시작"); TransactionStat..
OSIV 개요 JPA는 구현체를 Hibernate로 가지고 있습니다. QueryDsl 등을 통해서 쿼리문을 만드는 등 여러 추상화 기술을 이용하고 있기 때문에, 성능 상 조심해야 하는 점들이 있습니다. 그 중에 오늘은 OSIV에 대해 알아보겠습니다. 평소에 별로 고려하지 않았던 부분인데 실시간 서비스에서는 성능 상 이슈는 낼 수 있다는 것을 알고 공부하게 됐습니다. OSIV란? OSIV는 Open Session In View 의 약자로, 직역하면 View에서도 계속 Session이 Open 되어 있다는 뜻입니다. 즉, 사용자에게 보여지는 화면에서도 세션이 계속 유지됩니다. 비록 트랜잭션이 끝나도 말입니다. 트랜잭션에 관해서는 아래에서 설명하겠습니다. OSIV을 잘 이해하기 위해서 요청이 들어온 상황을 가정해보겠습..
일반 Join vs Fetch Join * 개요 Fetch Join를 공부하고 정말 좋은 기능이며 성능에 뛰어나다는 사실을 알았습니다. 그렇게 공부하던 중, 일반 Join과 Fetch Join은 구체적으로 어떤 차이가 있는지 궁금해졌습니다. 따라서 예제를 기반으로 내용을 정리합니다. * 조건 Author : Book이 1 : N로 연관관계를 가지고 있다고 가정합니다. 연관관계의 주인은 Author입니다. 특히, join은 FROM절에 N인 Book이 오느냐, 1인 Author가 오느냐에 따라서 성능이 차이가 납니다. 각 상황을 비교해봅니다. * Author @Entity public class Author implements Serializable { private static final long serialVersionUID = 1L; @I..
JPA를 이용해 History 테이블 자동 생성하기 개요 JPA를 이용해 생성시간, 수정시간, 생성자, 수정자를 자동으로 등록하는 방법을 공부했었습니다. 이번에는 JPA를 이용해서 특정 테이블을 저장할 때 히스토리를 같이 저장하도록 하겠습니다. history 테이블을 과거 이력을 확인할 때 용이합니다. 알림톡을 보냈거나, 사용자 권한이 변경된 기록들이 남아 있어 과거 이력을 추적할 수 있습니다. 만약 순수하게 만들어준다면 같은 데이터를 2번이나 save()해야 하는 번거로움이 있습니다. 하지만 @PrePersist, @PreUpdate를 사용하면 저장과 수정이후 JPA동작을 추가할 수 있습니다. 코드 작성하기 1. ApplicationContext로 직접 빈을 호출하는 유틸 클래스를 만든다. Entity에 Repository 주입이 불가능합니다. 따라서 ..
페치 조인 ( fetch join ) - 2 *목차 페치 조인 특징 3가지와 한계 1. 페치조인에 별칭을 줄 수 없다. 2. 둘 이상의 컬렉션을 페치조인 할 수 없다. 3. 컬렉션 페치조인은 페이징 API를 사용할 수 없다 - 페이징 API 한계 해결하기 1. 엔티티 페치조인 API로 뒤집기 2. LAZY 조회하기 3. @BatchSize 이용하기 * 페치 조인의 특징과 한계 1. 페치 조인 대상에는 별칭을 줄 수 없습니다. (하이버네이트는 가능하지만, 가급적 사용하지 않는다.) 페치 조인의 컨셉은 "나랑 연관되어 있는 애들을 모두 가져오겠다" 입니다. Team의 연관 컬렉션 Member가 5명인데 특정 3명만 조회하고 싶다면, 페치 조인을 가급적 사용하면 안됩니다. 무의식적으로 5명을 기대하고 Member 리스트를 사용할 가능성이 있습니다. //..
페치 조인 ( fetch join ) -1 *목차 fetch join 특징 설명 DB SQL, JPA fetch join 쿼리 비교 연관 엔티티 LAZY 조회 확인 한계 극복 fetch join을 이용한 연관 엔티티 조회 fetch join을 이용한 연관 컬렉션 조회 한계 극복 fetch join & 일반 조인 차이 * 페치 조인 특징 1. SQL 조인 종류가 아니다. 2 JPQL에서 성능 최적화를 위해 제공한다. 3. 연관된 엔티티나 컬렉션을 SQL 한번에 함께 조회한다. 페치 조인은, 일반적으로 SQL 문법을 사용했다면 낯선 용어입니다. 왜냐하면 전통 SQL의 방식이 아니기 때문입니다. 페치 조인은 JPQL에서 제공하는 쿼리 방식으로, 연관된 엔티티나 컬렉션을 한번에 조회하고 싶을 때 사용합니다. 일반적인 DB SQL과 JPA fetch jo..

728x90
반응형