학습목표

강의를 들으며 내가 알고 있는 내용을 점검하고,

새로 배운 내용을 정리하며,

궁금한 내용을 알아가며 학습해나가는 것을 목표로 합니다.

---

Spring Framework를 활용한 Data Layer 접근 방법

JDBC

자바 어플리케이션은 JDBC API를 이용하여 data 계층과 통신을 합니다.

1. Connection 획득
2. Statement를 이용한 질의
3. ResultSet을 이용한 질의 결과 사용
4. Statement, Connection 반납

이러한 일련의 번거로운 과정들을 단순화 할 순 없을까?

JDBC Template을 통하여 일련의 반복적인 작업들이 단순화 되기는 하였다. 그러나 exception의 경우, 우리가 try-catch 해주지는 않지만 언제나 jdbcTemplate에서 발생할 위험을 안고 있는 것 아닐까? 그러면 jdbcTemplate을 사용할 때는 이런 처리를 어떤 방식으로 할까?

토비의 스프링 - 예외 처리

JDBC Template

기존의 번거로운 과정들을 대신하여, JDBC Template을 이용해서, 데이터 계층에 접근이 가능합니다.

JDBC의 반복적인 작업을 JDBC Template이 대신 수행해 줍니다.

Mybatis (QueryMapper)

JDBC의 반복적인 작업을 쿼리매퍼인 Mybatis가 대신 수행 해줍니다.

자바 코드와 쿼리를 분리해주며, 쿼리가 수정되어도 자바 코드의 수정이나 컴파일을 다시 하는 작업을 하지 않아도 됩니다.

자바에서 쿼리를 쓰려면 String을 이용해야 구문 재활용이 가능합니다.

JPA

JPA를 사용함으로써 SQL 의존적인 개발에서 탈피하여, 객체 중심으로 생산적인 개발이 가능합니다.

객체지향 프로그래밍과 관계형 데이터 베이스의 패러다임 불일치에서 일어나는 문제점들이 해결 가능합니다.

JPA에서는 영속성 관리를 통해 엔티티의 필드 값이 추가 되거나 변경 되면 자동적으로 데이터가 바뀌게 됩니다.

JPA vendor adaptor

JPA는 인터페이스이기 때문에 어떠한 구현체를 사용해서 구현할 지 선택해야 합니다.

주로 Hibernate를 많이 사용합니다.

PlatformTransactionManager

Transaction을 관리해주는 객체입니다.

영속성 관리

JPA가 제공하는 기능은 크게 엔티티와 테이블을 매핑하는 설계 부분과

매핑한 엔티티를 실제 사용하는 부분으로 나눌 수 있습니다.

엔티티 매니저

엔티티 매니저는

엔티티를 저장하고, 수정하고, 삭제하고, 조회하는 엔티티와 관련된 모든 일을 처리합니다.

즉 엔티티를 저장하는 가상의 데이터베이스 같은 역할을 하는 엔티티 관리자입니다.

엔티티 매니저는 엔티티 매니저 팩토리를 통하여 생성 됩니다.

일반적으로 엔티티 팩토리는 비용이 많이 들기 때문에 하나만 생성하여 애플리케이션 전체에서 공유합니다.

엔티티 매니저 팩토리는 멀티-스레드 안정성이 보장되지만, 엔티티 매니저는 그렇지 않으므로 스레드 간에 공유하면 안 됩니다.

엔티티 매니저는 데이터베이스 연결이 필요한 시점까지 커넥션을 얻지 않습니다.

하이버네이트는 J2SE 환경에서는 커넥션 풀 도 만들고, J2EE 환경에서는 컨테이너가 제공하는 데이터 소스를 사용합니다.

영속성 컨텍스트

영속성 컨텍스트란 ‘엔티티를 영구 저장하는 환경' 을 의미합니다.

엔티티 매니저를 사용해서 엔티티를 영속성 컨텍스트에 저장하며 영속성 컨텍스트는 엔티티 매니저를 생성할 때 하나 만들어 집니다.

이런 영속성 컨텍스트는 실제로 존재한다기 보다는 논리적인 개념에 가깝습니다.

엔티티의 생명주기

• 비영속 : 영속성 컨텍스트와 전혀 관계가 없는 상태
• 영속 : 영속성 컨텍스트에 저장된 상태
• 준영속 : 영속성 컨텍스트에 저장 되었다가 분리된 상태
• 삭제

비영속

엔티티 객체를 생성한 상태이며 영속성 컨텍스트와 관련이 없습니다.

Member member = new Member();
member.setId("member1");
member.setUsername("회원");

영속

엔티티 매니저를 통해서 엔티티를 영속성 컨텍스트에 저장하였습니다.

이렇게 영속성 컨텍스트에 의해 관리하는 엔티티를 영속 상태라 합니다.

entityManager.persist(member);

준영속

영속성 컨텍스트에 의해 더이상 관리하지 않으면 준영속 상태입니다.

특정 엔티티를 준영속 상태로 바꾸는 방법은 아래와 같습니다.

• detach로 특정 엔티티만 준영속 상태로 만듬
• close로 영속성 컨텍스트를 닫음
• clear로 영속성 컨텍스트를 초기화 함

entityManager.detach(member);
// entityManager.close();
// entityManager.clear();

삭제

엔티티를 영속성 컨텍스트와 DB에서 삭제합니다.

entityManager.remove(member);

영속성 컨텍스트의 특징

1. 식별자 값

   영속성 컨텍스트는 엔티티를 식별자 값(@Id로 기본 키와 매핑한 값)으로 구분합니다.

   따라서 영속 상태는 식별자 값이 반드시 있어야 하며 없으면 예외가 발생합니다.

2. 데이터베이스 저장

   영속성 컨텍스트에 엔티티를 저장하면, 트랜잭션을 커밋하는 순간 데이터베이스에 이를 반영하는데 이것을 플러쉬라고 합니다.

영속성 컨텍스트의 장점

• 1차 캐시
• 동일성 보장
• 트랜잭션을 지원하는 쓰기 지연
• 변경 감지
• 지연 로딩

엔티티 조회

영속성 컨텍스트는 내부에 캐시를 가지고 있는데 이를 1차 캐시라고 합니다.

이 캐시는 키는 Id로 매핑한 식별자고, 값은 엔티티 인스턴스로 된 Map으로 관리 됩니다.

entityManager.find(Member.class, "member1");

find를 호출하면 1차 캐시에서 엔티티를 찾고 없으면 데이터베이스에서 조회합니다.

데이터베이스에서 엔티티를 생성해 1차 캐시에 저장한 후 영속 상태의 엔티티를 반환합니다.

결과적으로 데이터베이스 접근을 최대한 줄여 1차 캐시에서 처리하기 때문에 성능상 이점을 누릴 수 있습니다.

영속 엔티티의 동일성 보장

Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");

System.out.println(a == b);

• 결과는 ? True 같은 조회를 반복해서 호출해도 영속성 컨텍스트는 1차 캐시에 있는 같은 엔티티 인스턴스를 반환하기 때문에 참입니다. 즉 영속성 컨텍스트는 엔티티의 동일성을 보장합니다.
  

엔티티 등록

엔티티 매니저는 트랜잭션을 커밋하기 전까지 데이터베이스에 엔티티를 저장하지 않고 쓰기 지연 SQL 저장소에 INSERT SQL을 모아둡니다.

그리고 트랜잭션을 커밋하여 쿼리를 데이터베이스에 보내는데 이것을 트랜잭션을 지원하는 쓰기 지연이라고 합니다.

결국에는 데이터를 저장하는 즉시 쿼리로 보내든, 모아둬서 한 번에 보내든 트랜잭션을 커밋 하지 않으면 의미가 없기 때문에 쓰기 지연이 가능해진 것 입니다.

이러한 쓰기 지연을 통해 성능 최적화 할 수 있습니다.

엔티티 수정

💡 SQL 수정 쿼리의 문제점

SQL을 사용하면 수정 쿼리를 직접 작성해야 합니다.

그러나 프로젝트가 점점 커지고 요구사항이 늘어 나면서 수정 쿼리도 점점 늘어납니다.

여러 개의 쿼리를 사용하다 보면 많은 케이스를 고려하게 되어 수정 쿼리의 작성 소요가 늘어나게 되고,

이는 수정 쿼리가 많아지는 것은 물론이고 비즈니스 로직을 분석하기 위해 SQL을 확인하게 되어 비즈니스 로직이 SQL에 의존하게 됩니다.

변경 감지

JPA로 엔티티를 수정할 때는 엔티티를 조회해서 데이터만 변경하면 됩니다.

JPA는 엔티티의 변경 사항을 데이터베이스에 “변경 감지"라는 자동으로 반영하는 기능을 제공합니다.

이러한 변경감지를 가능하게 하기 위하여 엔티티를 영속성 컨텍스트에 보관할 때,

최초 상태를 보관해서 저장해 두는데 이를 스냅 샷이라고 합니다.

즉 아래와 같은 순서로 이루어집니다.

1. 트랜잭션을 커밋하면 엔티티 매니저 내부에서 플러시가 호출 됩니다.
2. 엔티티와 스냅샷을 비교해서 변경된 엔티티를 찾습니다.
3. 변경된 엔티티가 있으면 수정 쿼리를 생성해서 쓰기 지연 SQL 저장소에 보냅니다.
4. 쓰기 지연 저장소의 SQL을 데이터베이스에 보냅니다.
5. 트랜잭션을 커밋합니다.

변경 감지는 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용 됩니다.

JPA는 변경시 엔티티의 모든 필드를 업데이트 하는데, 이는 데이터 전송량이 증가하는 단점이 있지만

수정 쿼리가 항상 같기 때문에 애플리케이션 로딩 시점에 수정 쿼리를 미리 생성해두고 재사용 할 수 있고,

데이터베이스에 동일한 쿼리를 보내면 데이터베이스는 이전에 한 번 파싱된 쿼리를 재사용 할 수 있습니다.

하지만 필드가 많거나 저장되는 내용이 너무 크다면 @DynamicUpdate 로 수정된 데이터로만 동적으로 SQL을 생성할 수 있습니다.

@Entity
@org.hibernate.annotations.DynamicUpdate
@Table(name = "Member")
public class Member {...}

엔티티 삭제

삭제도 위의 과정과 비슷하게 엔티티를 조회 한 후 삭제 쿼리를 쓰기 지연 SQL 저장소에 등록합니다.

삭제를 호출하는 순간 헤당 엔티티는 영속성 컨텍스트에서 제거되기 때문에 이렇게 삭제된 엔티티는 재사용하지 말고 가비지 컬렉션의 대상이 되도록 두는 것이 좋습니다.

플러시(Flush)

플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영합니다.

플러시는 아래와 같은 순서로 동작합니다.

1. 변경 감지가 동작해서 영속성 컨텍스트에 있는 모든 엔티티를 스냅샷과 비교해서 수정된 엔티티를 찾습니다.수정된 엔티티는 수정 쿼리를 만들어 쓰기 지연 SQL 저장소에 등록합니다.
2. 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송합니다.

영속성 컨텍스트를 플러시하는 방법은 3가지입니다.

• entityManger.flush()를 직접 호출한다.
• 트랜잭션 커밋 시 플러시가 자동 호출된다.
• JPQL 쿼리 실행 시 플러시가 자동 호출된다.

직접 호출

직접 호출은 엔티티 매니저의 flush()를 직접 호출하여 영속성 컨텍스트를 강제로 플러시 합니다.

테스트나 다른 프레임워크와 JPA를 함께 사용할 때를 제외하고 거의 사용하지 않습니다.

트랜잭션 커밋 시 플러시 자동 호출

데이터베이스에 SQL을 전달하지 않고 트랜잭션만 커밋하면 아무 일도 일어나지 않습니다.

따라서 JPA는 트랜잭션을 커밋할 때 플러시를 자동으로 호출하여 이러한 문제를 차단합니다.

JPQL 쿼리 실행 시 플러시 자동 호출

객체지향 쿼리 호출 할 때도 플러시가 자동으로 호출됩니다.

em.persist(memberA); 
em.persist(memberB);
em.persist(memberC);

// 중간에 JPQL 실행
query = em.createQuery("select m from Member m", member.class); 
ist<Member> members = query.getResultList();

JPQL은 SQL로 변환되어 데이터베이스에서 엔티티를 조회합니다.

그런데 영속성 컨텍스트에 있지만 엔티티들이 데이터베이스에 반영되지 않았으므로,

쿼리를 실행하기 직전에 플러시를 통해 변경내용을 반영할 필요가 있습니다.

JPA는 이런 문제를 예방하기 위해 JPQL을 실행할 때도 플러시를 자동 호출 합니다.

플러시 모드 옵션

플러시는 커밋이나 쿼리를 실행할 때 자동 호출 되지만,

성능 최적화를 위해 커밋 할 때 만 플러시를 할 수 있게 설정할 수도 있습니다.

FlushModeType.AUTO
FlushModeType.COMMIT

준영속

준영속 상태의 엔티티는 영속성 컨텍스트에서 분리 되었기 때문에,

영속성 컨텍스트가 제공하는 기능을 사용할 수 없습니다.

엔티티를 준영속 상태로 만드는 방법은 크게 3가지 입니다.

• detach로 특정 엔티티만 준영속 상태로 만듬
• close로 영속성 컨텍스트를 닫음
• clear로 영속성 컨텍스트를 초기화 함

준영속 상태의 특징

• 거의 비영속 상태에 가깝다. 영속성 컨텍스트가 관리하지 않으므로 1차 캐시, 쓰기 지연, 변경 감지, 지연 로딩을 포함한 영속성 컨텍스트가 제공하는 어떠한 기능도 동작하지 않습니다.
  
• 식별자 값을 가지고 있다. 비영속 상태는 식별자 값이 없을 수도 있지만, 준영속 상태는 이미 한 번 영속 상태였으므로 반드시 식별자 값을 가지고 있습니다.
  
• 지연 로딩을 할 수 없다. 지연 로딩은 실제 객체 대신 프록시 객체를 로딩해두고 해당 객체를 실제로 사용할 때 영속성 컨텍스트를 통해 데이터를 불러오는 방법입니다. 하지만 준영속 컨텍스트는 영속상태가 아니므로 지연 로딩 시 문제가 발생합니다.
  

merge()

준영속 상태의 엔티티를 다시 영속 상태로 변경하려면 병합을 사용하면 됩니다.

merge 메소드는 준영속 상태의 엔티티를 받아 그 정보로 새로운 영속 상태의 엔티티를 반환합니다.

1. merge()를 실행합니다.
2. 파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티를 조회합니다
   1. 만약 1치 캐시에 엔티티가 없으면 데이터베이스에서 엔티티를 조회하고 1차 캐시에 저장합니다.
3. 조회한 영속 엔티티에 준영속 상태의 엔티티의 값을 채워 넣습니다.
4. 영속 엔티티를 반환합니다.

비영속 병합

병합은 비영속 엔티티도 영속 상태로 만들 수 있습니다.

식별자 값으로 엔티티를 조회할 수 있으면 영속성 컨텍스트나 데이터베이스에서 불러서 병합하고 조회할 수 없으면 새로 생성해서 병합합니다.

따라서 병합은 save or update 기능을 수행합니다.

정리

• 엔티티 매니저는 엔티티 매니저 팩토리에서 생성합니다. 영속성 컨텍스트는 엔티티 매니저를 통해서 접근할 수 있습니다.
• 영속성 컨텍스트는 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 합니다. 영속성 컨텍스트 덕분에 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 지연 로딩 기능을 사용할 수 있습니다.
• 영속성 컨텍스트에 저장한 엔티티는 플러시 시점에 데이터베이스에 반영되는데 일반적으로 트랜잭션을 커밋할 때 영속성 컨텍스트가 플러시 됩니다.
• 준영속 상태의 엔티티는 더는 영속성 컨텍스트의 관리를 받지 못하므로 영속성 컨텍스트가 제공하는 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 지연 로딩 같은 기능들을 사용할 수 없습니다.

Q. 준영속 상태에 무슨 의미가 있는지?

Q. 다시 persist하면 안되는 것인지? merge와 차이점?

https://www.youtube.com/watch?v=SavLrJfQ4Fs