컨넥션 풀이란, WAS(웹 컨테이너)가 실행 될 때 DB 연결을 위해 미리 일정 수의 Connection 객체를 만들어 Pool에 담아 뒀다가 고객의 요청이 발생하면 Pool에서 생성되어 있는 Connection 객체를 넘겨주고 고객이 사용이 끝나면 Connection 객체를 다시 Pool에 반환하여 보관하는 기법이다. 컨넥션 풀을
1. 커넥션 풀 동작 과정
고객이 DB를 사용하기 위해 Connection을 요청한다.
Connection Pool에서 사용되지 않고 있는 Connection 객체를 제공한다.
고객이 Connection 객체 사용 완료가 끝나면 Connection Pool로 반환한다.
2. 웹 애플리케이션에서 커넥션 풀을 사용해서 얻는 이점
🔍 서버 부하를 줄여준다.
자바에서 DB Connection을 맺는 과정은 부하가 많이 걸리는 작업이다.
따라서 많은 사람들이 동시에 DB 커넥션을 요구하는 경우 서버가 죽어버리는 문제가 발생할 수 있다.
이러한 문제를 해결하기 위해 미리 Connection 객체를 생성하고 재활용하여 서버에 부하를 줄여주는 용으로 사용한다.
🔍 서버의 한정적인 자원을 효율적으로 사용할 수 있다.
서버는 한정적인 자원을 가지고 있다.
요청이 올 때 마다 무제한의 Connection을 생성하게 된다면 전체 시스템 서능에 문제가 생길 수 있다.
이러한 문제를 해결하기 위해 커넥션 풀에 미리 정해진 숫자의 Connection 객체를 생성하여 관리한다.
🔍 고객이 기다려야하는 시간을 줄일 수 있다.
각 사용자에 대한 데이터 베이스 연결 요청은 시간과 비용이 비싸다.
Connection Pool에서는 Connectiuon이 생성 된 후 Pool에 배치하고 다시 사용되므로 새 연결을 설정할 필요가 없다.
따라서 데이터베이스에 대한 연결을 설정하기 위해 사용자가 기다려야하는 시간을 줄일 수 있다.
참고로 쓰레드 풀 (Thread Pool) 과 커넥션 풀 (Connection Pool)은 서로 다르다.
2. 엔티티의 생명주기
비영속(new/transient)
영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
영속 (managed)
영속성 컨텍스트에 관리되는 상태
준영속 (detached)
영속성 컨텍스트에 저장되었다가 분리된 상태
삭제 (removed)
삭제된 상태
🔍 비영속
JPA에 관계없이 그냥 객체 생성만 된 상태
// 객체를 생성한 상태(비영속)
Member member = new Member();
member.setId(100L);
member.setName("HelloWorld");
EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
EntityManager em = emf.createEntityManager();
// 객체를 생성한 상태 (비영속)
Member member = new Member();
member.setId(100L);
member.setName("HelloWorld");
// 객체를 저장한 상태 (영속)
em.persist(member);
🔍 준영속
EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
EntityManager em = emf.createEntityManager();
// 회원 엔티티를 영속성 컨텍스트에서 분리(준영속 상태)
em.detach(member);
준영속은 영속성 컨텍스트에서 해당 엔티티 객체를 삭제하는 것이다.
영속성 컨텍스트가 제공하는 기능을 사용하지 못한다.
한마디로 영속상태를 삭제시키는 것이다.
🔍 삭제
EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
EntityManager em = emf.createEntityManager();
// 객체를 삭제한 상태 (삭제)
em.remove(member);
실제 DB 삭제를 요청한 상태다.
3. 영속성 컨텍스트의 이점
1차 캐시
동일성(identity) 보장
트랜잭션을 지원하는 쓰기 지연 (transcational write-behind)
변경 감지 (Dirty Checking)
지연 로딩 (Lazy Loading)
🔍 엔티티 조회, 1차 캐시 (2차 캐시 도입 전)
1차 캐시는 영속성 컨텍스트 내부에 엔티티를 보관하는 저장소다.
영속성 컨텍스트를 엔티티 매니저로 이해해도 된다. 물론 미묘한 차이가 있긴 하다.
일반적으로 트랜잭션을 시작하고 종료될 때 까지만 1차 캐시가 유효하다.
엔티티 매니저는 데이터베이스 트랜잭션 단위로 생성이 된다. 트랜잭션이 끝나면 엔티티 매니저도 같이 종료된다. 그러면 1차 캐시도 같이 날라간다.
1차 캐시는 데이터베이스의 한 개의 트랜잭션 안에서만 효과가 있다. 애플리케이션이 공유하는 캐시는 2차 캐시라고 부른다.
그래서 1차 캐시로 얻는 성능의 이점이 크지 않다.
✔ 1차 캐시에서 조회
EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin();
try {
Member member = new Member(200L, "memberA");
// 1차 캐시에 저장됨
em.persist(member);
// 1차 캐시에서 조회
Member findMember = em.find(Member.class, 200);
tx.commit();
} catch (Exception e) {
tx.rollback();
} finally {
em.close();
}
emf.close();
find로 객체를 찾을 때 바로 DB에서 찾지 않고 1차 캐시를 먼저 조회한다.
1차 캐시의 수명은 트랜잭션의 수명과 같다.
persist로 저장된 객체는 영속성의 1차 캐시에 저장된다.
트랜잭션이 끝나기 전에 1차 캐시에 저장된 값을 조회하면1차 캐시에 저장된 값을 반환 받는다.
이 때 SQL SELECT 구문이 DB에 보내지 않고 바로 애플리케이션 단계에서만 일어난다.
결론적으로 1차 캐시에 존재하는 값을 조회할 경우 SQL SELECT 구문을 생성하지 않고 1차 캐시에서 값을 반환 받는다.
네트워크를 통해 데이터베이스를 접근하는 시간 비용은 애플리케이션 서버에서 내부 메모리에 접근하는 시간 비용보다 수만에서 수십만 배 이상 비싸다.
따라서 조회한 데이터를 메모리에 캐시해서 데이터 베이스 접근 횟수를 줄이면 애플리케이션 성능을 개선할 수 있다.
1차 캐시는 영속석 컨텍스트 내부에 존재하지만, 2차 캐시는 영속성 컨텍스트 외부에 존재한다.
1차 캐시는 트랜잭션이 시작부터 종료될 때 까지만 유효하기 때문에 데이터 베이스 접근 횟수를 획기적으로 줄일 수 없다.
1. 2차 캐시 적용 전
2. 2차 캐시 적용 후
3. 2차 캐시 동작 방식
동작 방식
엔티티 매니저는 최초 조회를 2차 캐시에 한다. 2차 캐시에 존재하지 않는다면 DB를 조회한다.
조회의 결과 값을 2차 캐시에 저장하고, 해당 엔티티의 복사 본을 1차 캐시인 영속성 컨텍스트에 반환한다.
동일 조회가 다른 영속성 컨텍스트에 들어오면 2차 캐시에 존재하는 엔티티를 복사하여 전달한다.
2차 캐시는 동시성을 극대화하기 위해 캐시한 객체의 본사본을 만들어서 반환한다.
만약 캐시한 원본 객체를 반환하면 동시에 여러 곳에서 해당 엔티티를 접근할 경우 문제가 생길 수 있기에 락을 걸어야 하므로 동시성이 떨어질 수 있다.
락에 비하면 객체를 복사하는 비용이 더 저렴하다.
알아야할 점은 2차 캐시는 데이터베이스의 기본 키를 기준으로 캐시하지만 영속성 컨텍스트가 다를 경우 객체의 동일성을 보장하지 않는다. (복사본을 반환하기 때문)
🔍 영속 엔티티의 동일성 보장
EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
EntityManager em = emf.createEntityManager();
Member a = em.find(Member.class, 100L);
Member b = em.find(Member.class, 100L);
System.out.println(a == b); // true
JPA는 영속 엔티티의 동일성을 보장한다. (1차 캐시가 있기에 가능하다.)
같은 트랜잭션 안에서 동일한 객체를 조회할 때 데이버베이스에서 가져오는 것이 아닌 애플리케이션 차원에서 객체를 제공한다.
🔍엔티티 등록 - 트랜잭션을 지원하는 쓰기 지연을 지원한다.
커밋 전까지는 SQL 구문을 데이터베이스에 보내지 않고 '쓰기 지연 SQL 저장소'에 저장한다. 커밋하는 순간 데이터 베이스에 SQL 구문을 보낸다. 한마디로 버퍼링 기능이다. 쓰기 지연을 통해서 쿼리를 여러번 날리지 않고 최적화가 가능하다.
package hellojpa;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.EntityTransaction;
import javax.persistence.Persistence;
public class JpaMain {
public static void main(String[] args) {
EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin();
try {
// 비영속
Member member1 = new Member(150L, "A");
Member member2 = new Member(150L, "B");
// 영속
em.persist(member1);
em.persist(member2); // 아직 엔티티 등록이 수행되지 않는다. (쓰기 지연)
System.out.println("=======================================");
tx.commit(); // 이 때 한꺼번에 엔티티 등록이 수행된다.
} catch (Exception e) {
tx.rollback();
} finally {
em.close();
}
emf.close();
}
}
/* 출력 결과 */
=======================================
Hibernate:
/* insert hellojpa.Member
*/ insert
into
Member
(name, id)
values
(?, ?)
Hibernate:
/* insert hellojpa.Member
*/ insert
into
Member
(name, id)
values
(?, ?)
출력 결과를 보면 알 수 있듯이 커밋전에는 SQL 구문을 데이터베이스에 보내지 않는다.
✔ commit 전
memberA와 memberB는 둘 다 쓰기지연 SQL 저장소에 저장되어 있고 실제 DB에 적용(저장)이 안된 상태다.
✔ commit 후
commit 시점에 '쓰기 지연 SQL 저장소'에 저장된 쿼리들을 다 실행시켜서 DB에 적용한다.
/* 출력 결과 */
Hibernate:
select
member0_.id as id1_0_0_,
member0_.name as name2_0_0_
from
Member member0_
where
member0_.id=?
=======================================
Hibernate:
/* update
hellojpa.Member */ update
Member
set
name=?
where
id=?
1차 캐시 안에는 @Id / Entity / 스냅샷이 존재한다.
여기서 스냅샷은 최초로 영속성 컨텍스트(1차 캐시)에 들어온 순간 스냅샷을 찍어서 저장한다.
JPA는 트랜잭션이 커밋(commit)되는 순간 엔티티와 스냅샷을 모두 비교한다.
변경된 것이 있을 경우 쓰기 지연 SQL 저장소에 업데이트 쿼리를 저장하고 수행한다.
🔍 엔티티 삭제
EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
EntityManager em = emf.createEntityManager();
//삭제 대상 엔티티 조회
Member memberA = em.find(Member.class, “memberA");
em.remove(memberA); //엔티티 삭제
![[JPA] 영속성 관리 - 내부 동작 방식](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2Fvf34q%2Fbtrxt1FzRTQ%2F1vk4LL3jsSXmxbhpr3MRf1%2Fimg.jpg)
