트랜잭션은 ACID라 하는 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)을 보장해야 한다. 원자성 트랜잭션 내에서 실행한 적업들은 마치 하나의 작업인 것처럼 모두 성공 또는 모두 실패해야 한다. 일관성 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다. 예를 들어 데이터베이스에서 정한 무결성 제약 조건을 항상 만족해야 한다. 격리성 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리한다. 예를 들어 동시에 같은 데이터를 수정하지 못하도록 해야한다. 격리성은 동시성과 관련된 성능 이슈로 인해 격리 수준을 선택할 수 있다. 지속성 트랜잭션을 성공적으로 끝내면 그 결과가 항상 기록되어야 한다. 중간에 시스템에 문제..
트랜잭션을 지원하는 쓰기 지연과 JDBC 배치 insert(member1); // INSERT INTO ... insert(member2); // INSERT INTO ... insert(member3); // INSERT INTO ... insert(member4); // INSERT INTO ... insert(member5); // INSERT INTO ... commit(); 위와 같은 경우는 5번에 INSERT SQL과 1번의 커밋으로 총 6번 데이터베이스와 통신한다. 이것을 최적화 하려면 SQL을 모아 한 번에 데이터베이스로 보내면 된다. JDBC가 제공하는 SQL 배치 기능을 사용하면 SQL을 모아서 데이터베이스에 한 번에 보낼 수 있다. 하지만 이 기능을 사용하려면 코드의 많은 부분을 수정..
수백만 건의 데이터를 배치 처리해야 하는 상황이라 가정해보자. 일반적인 방식으로 엔티티를 계속 조회하면 영속성 컨텍스트에 아주 많은 엔티티가 쌓이면서 메모리 부족 오류가 발생한다. 따라서 이런 배치 처리는 적절한 단위로 영속성 컨텍스트를 초기화 해야한다. 또한, 2차 캐시를 사용하고 있다면 2차 캐시에 엔티티를 보관하지 않도록 주의해야 한다. JPA 등록 배치 많은 엔티티를 한 번에 등록할 때 주의점은 영속성 컨텍스트에 엔티티가 계속 쌓이지 않도록 일정 단위마다 영속성 컨텍스트의 엔티티를 데이터베이스에 플러시하고 영속성 컨텍스트를 초기화해야 한다. EntityManager em = entityManagerFactory.createEntityManager(); EntityTransaction tx = em..
엔티티가 영속성 컨텍스트에 관리되면 1차 캐시부터 변경 감지까지 얻을 수 있는 혜택이 많다. 하지만 영속성 컨텍스트는 변경 감지를 위해 스냅샷 인스턴스를 보관하므로 더 많은 메모리르 사용하는 단점이 있다. 예를 들어 100건의 구매 내용을 출력하는 단순한 조회 화면이 있다고 가정해보자. 그리고 조회한 엔티티를 다시 조회할 일도 없고 수정할 일도 없이 딱 한 번만 읽어서 화면에 출력하면 된다. 이때는 읽기 전용으로 엔티티를 조회하면 메모리 사용량을 최적화할 수 있다. 스칼라 타입으로 조회 가장 확실한 방법은 다음처럼 엠티티가 아닌 스칼라 타입으로 모든 필드를 조회하는 것이다. 스칼라 타입은 영속성 컨텍스트가 결과를 관리하지 않는다. select o.id, o.name, o.price from Order o..
엔티티의 동등성 비교 영속성 컨텍스트 내부에는 엔티티 인스턴스를 보관하기 위한 1차 캐시가 있다. 이 1차 캐시는 영속성 컨텍스트와 생명주기를 같이 한다. 영속성 컨텍스트를 통해 데이터를 저장하거나 조회하면 1차 캐시에 엔티티가 저장된다. 이 1차 캐시 덕분에 변경 감지 기능도 동작하고, 이름 그대로 1차 캐시로 사용되서어 데이터베이스를 통하지 않고 데이터를 바로 조회할 수도 있다. 영속성 컨텍스트를 더 정확히 이해하기 위해서는 1차 캐시의 가장 큰 장점인 애플리케이션 수준의 반복 가능한 읽기를 이해해야 한다. 같은 영속성 컨텍스트에서 엔티티를 조회하면 다음 코드와 같이 항상 같은 엔티티 인스턴스를 반환한다. 단순이 동등성 비교 수준이 아니라 정말 주소값이 같은 인스턴스를 반환한다. Member memb..
JPA 표준 예외 정리 JPA 표준 예외들은 javax.persistence.PersistenceException의 자식 클래스다. 그리고 이 예외 클래스는 RuntimeException의 자식이다. 따라서 JPA 예외는 모두 언체크 예외다. JPA 표준 예외는 크게 2가지로 나눌 수 있다. 트랜잭션 롤백을 표시하는 예외 트랜잭션 롤백을 표시하지 않는 예외 트랜잭션 롤백을 표시하는 예외는 심각한 예외이므로 복구해선 안 된다. 이 예외가 발생하면 트랜잭션을 강제로 커밋해도 트랜잭션이 커밋되지 않고 대신에 javax.persistence.RollbackException 예외가 발생한다. 반면에 트랜잭션 롤백을 표시하지 않는 예외는 심각한 예외가 아니다. 따라서 개발자가 트랜잭션을 커밋할지 롤백할지를 판단하면..
엔티티 그래프란? 엔티티를 조회할 때 연관된 엔티티들을 함께 조회하려면 글로벌 fetch 옵션을 FetchType.EAGER로 설정하거나 OneToMnay 관계에 경우는 JPQL에서 페치 조인을 사용하면 된다. 글로벌 fetch 옵션은 애플리케이션 전체에 영향을 주고 변경할 수 없는 단점이 있기 때문에 보통 LAZY를 사용하고, 엔티티를 조회할 때 연관된 엔티티를 함께 조회할 필요가 있으면 JPQL의 페치 조인을 사용한다. 그러나 JPQL을 사용할때는 다른곳에서 요청하는 데이터에 맞게 여러개를 생성해야 한다. 모두 같은 엔티티를 조회하지만 sql이 모두 다른 경우가 많을 경우 너무 많은 메소드를 생성해야 한다. JPA 2.1에 추가된 엔티티 그래프 기능을 사용하면 엔티티를 조회하는 시점에 함께 조죄할 연..
모든 엔티티를 대상으로 언제 어떤 사용자가 삭제를 요청했는지 모두 로그를 남겨야 하는 요구사항이 있다고 가정하자. 이때 애플리케이션 삭제 로직을 하나씩 찾아서 로그를 남기는 것은 너무 비효율적이다. JPA 리스너 기능을 사용하면 엔티티의 생명주기에 따른 이벤트를 처리할 수 있다. 이벤트 종류 PostLoad 엔티티가 영속성 컨텍스트에 조회된 직후 또는 refresh를 호출한 후(2차 캐시에 저장되어 있어도 호출된다) PrePersist persist() 메소드를 호출해서 엔티티를 영속성 컨텍스트에 관리하기 직전에 호출된다. 식별자 생성 전략을 사용한 경우 엔티티에 식별자는 아직 존재하지 않는다. 새로운 인스턴스를 merge 할 때도 수행된다. PreUpdate flush나 commit을 호출해서 엔티티를..
컨버터를 사용하면 엔티티의 데이터를 변환해서 데이터베이스에 저장할 수 있다. 예를 들어 회원의 VIP여부를 데이터베이스에는 "Y", "N"으로 저장하고 엔티티에서는 boolean 타입으로 변환해서 사용할 수 있다. @Entity public class Member { ... @Convert(converter = VipConverter.class) private boolean isVip; } @Converter public class VipConverter implements AttributeConverter { // 엔티티의 데이터를 데이터베이스 컬럼에 저장할 데이터로 변환 @Override public String convertToDatabaseColumn(Boolean attribute) { retu..
스프링은 컨테이너는 트랜잭션 범위의 영속성 콘텍스트 전략을 기본으로 사용한다. 트랜잭션이 같으면 같은 영속성 콘텍스트가 콘텍스트가 공유되고 트랜잭션이 끝나면 영속성 콘텍스트가 닫히는 것이다. 그럼 트랜잭션이 끝나고 엔티티에 지연 로딩으로 연결된 다른 엔티티를 불러오면 어떻게 될까? 보통 트랜잭션은 비즈니스 로직이 있는 서비스단에서 시작하고 종료한다. public class Member { ... @ManyToOne(fetch = FetchType.LAZY); private Team team; } Member member = memberService.getMember(1); // 트랜잭션 종료, 준영속 상태 member.getTeam(); // 종료 후 지연로딩으로 연결된 team 정보 조회 당연히 영속성..