트랜잭션과 락 트랜잭션과 격리 수준 트랜잭션 특성 원자성: 트랜잭션 내에 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공하든가 모두 실패해야 한다. 일관성: 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다. 격리성: 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리한다. 지속성: 트랜잭션을 성공적으로 끝내면 그 결과가 항상 기록되어야 한다. 트랜잭션은 원자성, 일관성, 지속성을 보장한다. 문제는 격리성인데 트랜잭션 간에 격리성을 완벽히 보장하려면 트랜잭션을 거의 차례대로 실행해야 한다. 이렇게하면 동시성 처리 성능이 매우 나빠진다....
예외 처리 JPA 표준 예외 정리 JPA 표준 예외들은 PersistenceException의 자식 클래스다. 그리고 이 예외 클래스는 RuntimeException의 자식이므로 JPA 예외는 모두 언체크 예외다. JPA 표준 예외는 2가지로 나눌 수 있다. 트랜잭션 롤백을 표시하는 예외: 심각한 예외이므로 복구해선 안 된다. 트랜잭션을 강제로 커밋해도 트랜잭션이 커밋되지 않고 대신 RollbackException이 발생한다. 트랜잭션 롤백을 표시하지 않는 예외 심각한 예외가 아니다. 스프링 프레임워크의 JPA 예외 변환 서비스 계층에서 데이터 접근 계층의 구현 기술에 직접 의존하는 것은 좋은 설계라 할 수 없다....
트랜잭션 범위의 영속성 컨텍스트 스프링 컨테이너의 기본 전략 스프링 컨테이너는 트랜잭션 범위의 영속성 컨텍스트 전략을 기본으로 사용한다. 트랜잭션을 시작할 때 영속성 컨텍스트를 생성하고 트랜잭션이 끝날 때 영속성 컨텍스트를 종료한다. 트랜잭션이 같으면 같은 영속성 컨텍스트를 사용한다. 다양한 위치에서 엔티티 매니저를 주입받아 사용해도 트랜잭션이 같으면 항상 같은 영속성 컨텍스트를 사용한다. 따라서 엔티티 매니저는 달라도 같은 영속성 컨텍스트를 사용한다. 트랜잭션이 다르면 다른 영속성 컨텍스트를 사용한다. 여러 스레드에서 동시에 요청이 와서 같은 엔티티 매니저를 사용해도 트랜잭션에 따라 접근하는 영속성 컨텍스트가 다르다....
컬렉션 JPA는 자바에서 기본으로 제공하는 Collection, List, Set, Map 컬렉션을 지원하고 다음 경우에 이 컬렉션을 사용할 수 있다. @OneToMany, @ManyToMany를 사용해서 일대다나 다대다 엔티티 관계를 매핑할 때 @ElementCollection을 사용해서 값 타입을 하나 이상 보관할 때 JPA와 컬렉션 하이버네이트는 엔티티를 영속 상태로 만들 때 컬렉션 필드를 하이버네이트에서 준비한 컬렉션으로 감싸서 사용한다. Collection, List ArrayList로 초기화하면 된다. Collection, List는 중복을 허용한다고 가정하므로 add() 메소드는 내부에서 어떤 비교도 하지 않고 항상 true를 반환한다. 같은 엔티티가 있는지 찾거나 삭제할 때는 equals() 메소드를 사용한다....
JPA를 사용해서 데이터 접근 계층을 개발할 때도 유사한 코드를 반복해서 개발해야 한다. 이런 문제를 해결하려면 제네릭과 상속을 적절히 사용해서 공통 부분을 처리하는 부모 클래스를 만들면 되지만, 공통 기능이 부모 클래스에 너무 종속되고 구현 클래스 상속이 가지는 단점에 노출된다. 스프링 데이터 JPA 소개 스프링 데이터 JPA는 데이터 접근 계층을 개발할 때 구현 클래스 없이 인터페이스만 작성해도 개발을 완료할 수 있다. MemberRepository.findByUsername() 처럼 직접 작성한 메소드도 메소드 이름을 분석해서 다음 JPQL을 실행한다....
객체지향 쿼리 소개 JPQL 특징 테이블이 아닌 객체를 대상으로 검색하는 객체지향 쿼리다. SQL을 추상화해서 특정 데이터베이스 SQL에 의존하지 않는다. 다음은 JPA가 공식 지원하는 기능이다. JPQL Criteria 쿼리: JPQL을 편하게 작성하도록 도와주는 API, 빌더 클래스 모음 네이티브 SQL: JPA에서 JPQL 대신 직접 SQL을 사용할 수 있다. 다음은 JPA가 공식 지원한느 기능은 아니지만 알아둘 가치가 있다. QueryDSL: Criteria 쿼리처럼 JPQL을 편하게 작성하도록 도와주는 빌더 클래스 모음, 비표준 오픈소스 프레임워크다. JDBC 직접 사용, MyBatis 같은 SQL 매퍼 프레임워크 사용: 필요하면 JDBC를 직접 사용할 수 있다....
값 타입 3가지 기본값 타입 자바 기본 타입(int, double) 래퍼 클래스(Integer) String 임베디드 타입 컬렉션 값 타입 기본값 타입 값 타입은 다른 엔티티와 공유하면 안 된다. 임베디드 타입(복합 값 타입) 임베디드 타입을 사용하려면 다음 2가지 어노테이션이 필요하다. 참고로 둘 중 하나는 생략해도 된다. @Embeddable: 값 타입을 정의하는 곳에 표시 @Embedded: 값 타입을 사용하는 곳에 표시 임베디드 타입은 기본 생성자가 필수다. 임베디드 타입과 테이블 매핑 잘 설계한 ORM 애프리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다....
프록시 지연 로딩: 엔티티가 실제 사용될 때까지 데이터베이스 조회를 지연하는 방법 지연 로딩 기능을 사용하려면 실제 엔티티 객체 대신 데이터베이스 조회를 지연할 수 있는 가짜 객체가 필요한데 이것을 프록시 객체라 한다. JPA 표준 명세는 지연로딩의 구현 방법을 JPA 구현체에 위임했다. 하이버네이트는 지연 로딩을 지원하기 위해 프록시를 사용하는 방법과 바이트코드를 수정하는 두 가지 방법을 제공한다. 프록시 기초 엔티티를 직접 조회하면 조회한 엔티티를 실제 사용하든 사용하지 않든 데이터베이스를 조회하게 된다. Member member = em....
상속 관계 매핑 관계형 데이터베이스에는 객체지향 언어에서 다루는 상속이라는 개념이 없다. 슈퍼타입 서브타입 논리 모델을 실제 물리 모델인 테이블로 구현하는 방법 3가지 조인 전략: 모두 테이블로 만들고 조회할 때 조인을 사용한다. 단일 테이블 전략: 테이블을 하나만 사용해서 통합한다. 구현 클래스마다 테이블 전략: 서브 타입마다 하나의 테이블을 만든다. 조인 전략 엔티티 각각을 모두 테이블로 만들고 자식 테이블이 부모 테이블의 기본 키를 받아서 기본 키 + 외래 키로 사용하는 전략 주의 점: 타입을 구분하기 위한 컬럼이 추가 되어야 한다....
엔티티 연관관계를 매핑할 때는 3가지를 고려해야 한다. 다중성 다대일 일대다 일대일 다대다 단방향, 양방향 객체 관계에서 한 쪽만 참조하는 것을 단방향 관계, 양쪽이 서로 참조한느 것을 양방향 관계라 한다. 연관관계의 주인 두 객체의 연관관계 중에서 외래 키를 관리하는 객체를 연관관계의 주인이라 한다. 외래 키를 가진 테이블과 매핑한 엔티티가 외래 키를 관리하는 게 효율적이므로 보통 이곳을 연관관계의 주인으로 선택한다. 다대일 일대다 또는 다대일 관계에서 외래 키는 항상 다쪽에 있다. 따라서 객체 양방향 관계에서 연관관계의 주인은 항상 다쪽이다....
방향 단방향: 객체의 한 쪽만 참조하는 것 양방향: 객체가 서로 참조하는 것 다중성: N:1, 1:N, 1:1, N:M 연관관계 주인: 객체를 양방향 영관관계로 만들면 연관관계의 주인을 정해야 한다. 단방향 연관관계 객체는 참조(주소)로 연관관계를 맺는다. 테이블은 외래 키로 연관관계를 맺는다. 참조를 사용하는 객체의 연관관계는 단방향이다. A -> B (a.b) 외래 키를 사용하는 테이블의 연관관계는 양방향이다. A JOIN B가 가능하면 반대로 B JOIN A 도 가능하다. 객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다....
@Entity JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 어노테이션을 필수로 붙여야한다. @Entity 적용 시 주의사항 기본 생성자가 필수다(파라미터가 없는 public 또는 protected 생성자) final 클래스, enum, interface, inner 클래스에는 사용할 수 없다. 저장할 필드에 final을 사용하면 안 된다. kotlin을 사용할 때는 maven의 jpa 플러그인을 사용 한다면 파라미터가 없는 생성자를 만들 필요가 없다. (https://kotlinlang.org/docs/no-arg-plugin.html#jpa-support) kotlin을 사용할 때는 기본적으로 final 클래스로 만들어지는데, 아래와 같이 플러그인을 이용해서 특정 어노테이션이 붙어 있는 경우에는 open 클래스로 만들도록 수정할 수 있다....
앤티티 매니저(Entity Manager)는 엔티티를 저장하고, 수정하고, 삭제하고, 조회하는 등 엔티티와 관련된 모든 일을 처리한다. 개발자 입장에서 엔티티 매니저는 엔티티를 저장하는 가상의 데이터베이스로 생각하면 된다. 엔티티 매니저 팩토리와 엔티티 매니저 데이터베이스 하나만 사용하는 애플리케이션은 일반적으로 EntityManagerFactory를 하나만 생성한다. 엔티티 매니저 팩토리는 엔티티 매니저를 만드는 공장인데 ,공장을 만드는 비용은 상당히 크다. 따라서 한 개만 만들어서 애플리케이션 전체에서 공유하도록 설계되어 있다. 엔티티 매니저 팩토리는 여러 스레드가 동시에 접근해도 안전하므로 서로 다른 스레드 간에 공유해도 되지만, 엔티티 매니저는 여러 스레드가 동시에 접근하면 동시성 문제가 발생하므로 스레드 간에 절대 공유하면 안 된다....
객체 매핑 시작 CREATE TABLE MEMBER ( ID VARCHAR(255) NOT NULL, NAME VARCHAR(255), AGE INTEGER, PRIMARY KEY(ID) ) @Entity @Table(name = "MEMBER") class Member( @Id @Column(name = "ID") var id: String, @Column(name = "NAME") var username: String, var age: Int, ) @Entity: 이 클래스를 테이블과 매핑된다고 JPA에게 알려준다. @Table: 엔티티 클래스에 매핑할 테이블 정보를 알려준다. name 속성을 사용해 Member엔티티를 MEMBER 테이블에 매핑했다. @Id: 엔티티 클래스의 필드를 테이블의 기본 키에 매핑한다. @Column: 필드를 컬럼에 매핑한다....
SQL을 직접 다룰 때 발생하는 문제점 반복, 반복 그리고 반복 객체를 데이터베이스에 CRUD하려면 너무 많은 SQL과 JDBC API를 코드로 작성해야 한다. SQL 작성 JDBC API를 사용해서 SQL 실행 SQL과 객체의 매핑 테이블마다 이런 일을 반복해야 해서 작성해야 된다. SQL에 의존적인 개발 Member 객체에 새로운 필드 Team을 추가할 경우 클래스에 필드 추가 CRUD 쿼리 수정 연관 관계 매핑을 위한 JOIN 쿼리가 있는 새로운 DAO 메소드 추가 Member 객체는 team 필드가 있는지 확인하기 위해 DAO를 열어서 SQL을 확인할 수 밖에 없다....