더 이상 물러설 곳이 없다

객체가 RDB에 매핑될 때 반드시 PK로 사용할 멤버변수를 지정해줘야 한다.

이때 @Id 어노테이션을 사용하는데, 이것만 사용할 경우 다른 컬럼들과 똑같이 PK값도 일일히 직접 할당해주게 된다.

보통 PK에 대해서는 이런 식으로 하지 않고 값이 알아서 자동적으로 할당되도록 하는 것이 좋다.

이를 위해 @Genera5tedValue 어노테이션을 추가로 사용하는데 여기에 적용되는 여러 가지 옵션이 있다.

그 중 가장 대표적인 방식은 IDENTITY, SEQUENCE 방식이다.

1. IDENTITY

@Entity 
public class Member { 
    @Id 
    @GeneratedValue(strategy = GenerationType.IDENTITY) 
    private Long id; 
}

PK의 생성을 데이터베이스가 대신 할당하도록 한다. 주로 MySQL에서 사용되는 방식이다.

(오라클은 IDENTITY 지원하지 않음)

IDENTITY 전략을 사용할 때 영속성 컨텍스트는 평소와는 조금 다르게 동작한다.

em.persist()로 영속성 컨텍스트에 객체를 저장하게 되면 해당 객체는 영속성 컨텍스트에 있는 1차 캐시 안에서 Key-Value 쌍으로 존재하게 된다.

이때 Key = PK, Value = Object의 형태로 존재하게 되는데.. IDENTITY 방식은 엔티티가 실질적으로 DB에 저장되는 순간 DB에서 자동으로 PK값을 할당해주는 방식이다.

하지만 트랜잭션이 커밋되기 전까지 해당 객체에 대한 쿼리는 DB에 적용되지 않는다. 

즉, 커밋이 이뤄지기 전까지는 PK를 가질 수 없다는 것. 그런데 영속성 컨텍스트 안에서는 PK-Object의 키밸류 페어로 존재해야 한다.

이를 해결하기 위해서 IDENTITY 전략을 사용할 때는 예외적으로 em.persist()를 호출했을 때 즉각적으로 DB에 실제 쿼리를 날려버린다.

2. SEQUENCE

@Entity 
@SequenceGenerator( 
        name = “MEMBER_SEQ_GENERATOR", 
        sequenceName = “MEMBER_SEQ", // 매핑할 데이터베이스 시퀀스 이름
        initialValue = 1, allocationSize = 1) 
public class Member { 
    @Id 
    @GeneratedValue(strategy = GenerationType.SEQUENCE, 
            generator = "MEMBER_SEQ_GENERATOR") 
    private Long id; 
}

SEQUENCE 전략은 DB의 시퀀스 오브젝트를 사용하여 PK값을 자동할당한다. 주로 오라클 디비에서 사용되는 방식이다.

(MySQL은 SEQUENCE 지원하지 않음)

이를 위해 @SequenceGenerator를 통해 사용할 시퀀스 오브젝트를 직접 생성해줘야 한다.

em.persist()를 수행하면 DB의 시퀀스 오브젝트에게서 1차캐시에 Key값으로 저장될 PK값을 할당받아 객체와 함께 영속성 컨텍스트 안에 저장한다.

(이떄 IDENTITY 전략 처럼 DB에 쿼리가 날아가는 것은 아니다)

하지만 PK 하나가 필요할 때마다 매번 디비쪽과 네트워크 통신을 하기 때문에 성능에 대한 문제가 있을 수 있다. 이를 방지하기 위해 @SequenceGenerator의 allocationSize 속성이 존재한다.

allocationSize는 한 번의 시퀀스 접근을 통해 사용할 수 있는 PK값의 개수를 의미한다.

allocationSize의 디폴트 값은 50인데, 이 경우 한 번의 DB 접근만으로 50개의 PK값을 얻어와 메모리에 저장한 뒤 영속성 컨텍스트에 객체를 저장할 때마다 메모리에서 PK를 하나씩 가져와 할당하는 것이다.

이렇게 하면 네트워크 접근 횟수를 비약적으로 줄일 수 있게 된다.

시퀀스 동작에 대한 좀 더 자세한 설명은 아래 질문글 링크를 참고

https://www.inflearn.com/questions/116520

EntityManager를 사용해 작업을 수행해도 commit을 하기 전까지는 작업의 결과들이 DB에 반영되지 않는다고 했었다.

정확히는 "Flush가 호출되기 전에는 DB에 반영되지 않는다"가 맞다.

Flush가 호출되면 영속성 컨텍스트 안에 보관되고있던 이전 작업들에 대한 결과가 실제 DB에 반영이 된다.

(영속성 컨텍스트를 비우는 것이 아니라 영속성 컨텍스트의 변경내용을 DB에 적용시켜 주는 것이다)

영속성 컨텍스트를 Flush하는 방법은 세 가지가 존재한다.

(사실 실전에서 직접적으로 도움이 되는 내용은 아니지만 테스트 등에서 사용될 수 있다)

1. em.flush()

-> 그냥 직접 호출하는 것이다.

2. transaction.commit()

-> 트랜잭션 커밋을 수행하면 플러시가 자동으로 호출된다.

3. JPQL

-> JPQL 쿼리를 실행하면 플러시가 자동으로 호출된다.

-> JPQL은 SQL로 번역되어 DB에 바로 접근하게 된다. 이 경우에 만약 영속성 컨텍스트의 내용이 DB에 적용되지 않은 상태로 JPQL이 수행된다면 문제가 발생할 수 있으므로 JPQL 전에는 항상 flush를 먼저 수행한다.

영속성 컨텍스트의 생존 범위는 반드시 트랜잭션과 함께 동작하도록 해야 한다.

스프링 프레임워크를 사용하면 스프링에 의해 트랜잭션이 종료될 때 영속성 컨텍스트도 함께 종료되도록 동작한다.

JPA는 왜 Java "Persistence" API인가? 바로 Persistence Context를 사용하기 때문.

맨 처음 웹 애플리케이션이 실행되면 EntityManagerFactory라는 녀석이 생성되고 그 후 사용자의 요청이 들어올 때마다 각각의 EntityManager를 만들어서 요청을 수행한다.

Persistence Context (영속성 컨텍스트)는 이 EntityManager안에 들어있는 녀석인데 이것이 자바 코드와 DB 사이에서 중간자 역할을 한다.

굳이 의미를 풀자면 "엔티티를 영구적으로 저장하는 환경" 정도가 된다.

객체를 엔티티로서 디비에 저장하거나 디비의 엔티티를 객체로 가져오는 명령을 내릴 때 해당 엔티티틑 영속성 컨텍스트 안에 존재하고 있다가 트랜잭션 커밋이 이뤄질 때 쿼리를 DB에 전달하여 동작을 완전히 수행한다.

이러한 영속성 컨텍스트 안에서 엔티티는 네 가지 생명주기를 갖는다.

1. 비영속 (new / transient)

-> 영속성 컨텍스트와 전혀 관계가 없는 상황. 새로 생성한 객체를 em.persist() 하기 전 이 객체는 '비영속' 상태에 해당된다.

2. 영속성 (managed)

-> 영속성 컨텍스트 안에서 관리되고 있는 상태. em.persist()를 하고난 이후의 객체가 '영속성' 상태에 해당된다.

3. 준영속 (detached)

-> 영속성 컨텍스트 안에 존재하다가 분리된 상태. em.persist(member)로 영속성 컨텍스트 안에 들어갔다가 em.detach(member)로 다시 분리하면 이때의 상태가 '준영속' 상태에 해당된다.

4. 삭제 (removed)

-> 객체를 완전히 삭제한 상태. 영속성 컨텍스트 안에 존재하는 객체에 대해 em.remove(member)하여 객체를 삭제하면 이 때의 상태가 '삭제' 상태이다.

비영속 상태와 준영속 상태는 같은 것이 아닌가 싶었는데 그에 대한 해답을 아래 링크에서 찾을 수 있었다.

www.inflearn.com/questions/45195      

영속성 컨텍스트 안에는 1차 캐시가 존재하여 캐싱을 지원한다.

그렇긴 한데 이게 실제 상황에서 그렇게 큰 시간절약을 이루어주지는 않는다고 한다.

단 건에 대한 기본적인 CRUD 기능은 아래와 같이 간편하게 사용할 수 있었다.

        EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();

        Member member = new Member();
        member.setId(1L);
        member.setName("name1");
        
        // Create
        em.persist(member);  // list.add(Object o) 처럼 간편하게 DB에 객체 저장
        // Read
        Member findMember = em.find(Member.class, 1L);  // PK를 사용하여 간편하게 읽어옴
        // Update
        findMember.setName("change name");  // 조회한 객체에 대하여 수정을 하는 것만으로 update쿼리까지 완료됨
        // Delete
        em.remove(member);  // 조회한 객체를 삭제하면 테이블에서도 해당 엔티티 바로 삭제됨

        tx.commit();

그럼 좀 더 복잡한 경우에 대해서는 어떻게 해야할까? 

여러 개의 행을 반환해야 하거나 검색 조건을 넣어 조회를 해야한다면?

이런 경우에는 약간의 쿼리 작성이 필요하다. 하지만 DB 테이블을 기준으로 쿼리를 작성하지 않는다.

그게 무슨 말이지?

->

JPA의 존재 의의는 DB 테이블에 종속되지 않고 엔티티 객체 중심적으로 개발을 하기 위함이다.

그렇기에 부득이하게 쿼리를 짜야하는 일이 있어도 객체에 초점을 맞춰 쿼리를 작성한다.

만약 실제 물리적 DB에 맞춰 쿼리를 짠다면 그것은 DB에 종속적인 설계가 되는 것이고 이는 JPA의 사용 취지에 어긋난다.

// 여러 건의 검색 결과를 List에 담아 반환한다.
List<Member> result = em.createQuery("select m from Member as m", Member.class).getResultList();

위와 같은 문제를 해결하기 위해 JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어를 제공한다.

쿼리를 자세히 보면 지금까지 작성했던 쿼리와의 차이점을 알 수 있다.

from table_name이 아닌 from class_name의 형식으로 작성된 쿼리이다.

이런식으로 객체 중심적으로 쿼리를 작성하면 이 역시 JPA가 Member클래스에 해당하는 테이블명에 대한 쿼리를 알아서 날려서 조회를 해준다.

이렇게 객체 중심적으로 작성하는 쿼리를 JPQL(Java Persistence Query Language)라고 한다.

JPQL은 SELECT, FROM, WHERE, GROUP BY, HAVING, JOIN을 지원한다.

요즘은 NoSQL도 많이 사용한다지만 아직 가장 보편적인 데이터베이스는 RDB(Relational Database)이다.

객체지향 프로그래밍을 하면서 생성한 도메인 객체들은 관계형 데이터베이스에 저장되어서 관리된다.

즉, 도메인 클래스가 DB의 테이블과 대응되고 해당 클래스의 객체는 테이블의 엔티티로서 저장되는 것이다.

이를 위해서는 RDB 테이블에 해당 객체를 매핑(Mapping)시켜줘야 한다.

이를 ORM(Object Relational Mapping)이라고 한다.

고대(?) 자바 개발에서는 이 모든 작업을 JDBC를 통해 처리했다.

그런데 이 방법은 드라이버를 연결하고 SQL을 문자열로 하나하나 직접 작성하는 기계적이고 반복적인 작업에 소요되는 시간이 너무나 컸다.

너무나도 불필요한 낭비였지만 다른 대안이 없었기에 불가피했다.

또한 아무리 객체를 RDB에 매핑하여 저장한다지만 이 둘이 상속, 연관관계, 데이터 타입, 데이터 식별 방법 등 본질적인 패러다임까지 완전히 같은 것은 아니기에 여러 가지 문제들이 발생했다.

이런 배경 속에 등장한 것이 JPA(Java Persistence API)이다.

JPA는 객체를 마치 자바 Collections에 저장해 관리하는 것처럼 편리하게 DB에 저장할 수 있도록 해주는 ORM 프레임워크이다.

RDB는 RDB대로 그 특성에 맞게 설계하고 객체는 객체대로 설계한다. 사용자는 편하게 객체를 저장하고 귀찮은 매핑 작업은 전부 JPA가 처리한다.

즉, 패러다임의 불일치에 대해서 신경쓰지 않고 작업하는 것이다.

하지만 내부적으로는 여전히 JDBC가 사용된다. 사용자가 직접 사용하진 않게 되었지만 사용자 편하게 내린 명령을 JPA가 이전까지 해왔던 JDBC를 사용한 그런 복잡한 과정들을(SQL을 하나하나 작성하는 등) 거쳐 RDB에 매핑해주는 것이다.

기본적인 CRUD 기능에 대한 쿼리는 내부적으로 JPA가 전부 알아서 짜주기 때문에 더 이상 기계적, 반복적인 SQL 작업에 오랜 시간 고통받을 필요가 없어졌다.

JPA는 인터페이스의 모음이고 그것을 상속한 클래스가 여러 가지 존재하지만 hibernate가 대표적으로 사욯된다.

아래와 같은 방식으로 가장 기본적인 CRUD 기능을 쿼리 작성 없이 간단하게 사용할 수 있다.

        EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();

        Member member = new Member();
        member.setId(1L);
        member.setName("name1");
        
        // Create
        em.persist(member);  // list.add(Object o) 처럼 간편하게 DB에 객체 저장
        // Read
        Member findMember = em.find(Member.class, 1L);  // PK를 사용하여 간편하게 읽어옴
        // Update
        findMember.setName("change name");  // 조회한 객체에 대하여 수정을 하는 것만으로 update쿼리까지 완료됨
        // Delete
        em.remove(member);  // 조회한 객체를 삭제하면 테이블에서도 해당 엔티티 바로 삭제됨

        tx.commit();

그런데, 위의 CRUD는 모두 하나의 객체에 대한 작업이다.

그럼 특정 조건의 엔티티 여러 개를 조회해야 하는 등 더 복잡한 경우엔 어떻게 할까?

이것을 위한 JPQL을 이 다음 글에서 설명한다.