728x90
반응형
SMALL
SMALL

2024.10.25 업데이트


 

영속성 컨텍스트는 JPA에서 가장 중요한 개념 중 하나이다. 이 PersistenceContext를 이해해야만 JPA를 이해할 수 있다고 봐도 무방하다. 

 

공부하는데 도움을 받은 김영한 강사님의 "자바 ORM 표준 JPA 프로그래밍" 추천합니다.

출처: https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

 

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

초급자를 위해 준비한 [웹 개발, 백엔드] 강의입니다. JPA를 처음 접하거나, 실무에서 JPA를 사용하지만 기본 이론이 부족하신 분들이 JPA의 기본 이론을 탄탄하게 학습해서 초보자도 실무에서 자

www.inflearn.com

 

엔티티 매니저 팩토리와 엔티티 매니저

우선 영속성 컨텍스트를 알기 전 엔티티 매니저 팩토리와 엔티티 매니저를 그림으로 이해해보자. 

애플리케이션이 실행되면 딱 한번 엔티티 매니저 팩토리가 만들어 지는데, 이 팩토리로부터 엔티티 매니저가 생성된다. 언제? 고객의 요청이 들어오면. 들어와서, 트랜잭션이 필요해다고 개발자가 지정한 지점에.

 

고객의 요청 중 트랜잭션이 필요한 요청 하나에 하나의 엔티티 매니저가 생성된다고 보면 되고 그 엔티티 매니저는 커넥션풀에서 커넥션을 사용한다. 그렇기에 엔티티 매니저가 할 일을 다했으면 반드시 엔티티 매니저를 닫아줘야 한다는 것이다. 사용하지 않는데 커넥션을 계속 잡고 있으면 이후에 들어오는 고객의 요청은 응답할 수 없을테니까.

 

 

영속성 컨텍스트

그럼 영속성 컨텍스트는 무엇이며 어디에 있을까? 영속성 컨텍스트는 엔티티를 영구 저장하는 환경 또는 컨텍스트인데 엔티티 매니저와 1:1 매핑이 된다. 즉, 엔티티 매니저 하나가 생성되면 그 엔티티 매니저가 가지는 영속성 컨텍스트 하나가 생성된다.

 

영속성 컨텍스트로부터 엔티티는 생명 주기를 가지는데, 4단계로 구분된다.

- 비영속 (new/transient): 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태

- 영속 (managed): 영속성 컨텍스트에 관리되는 상태

- 준영속 (detached): 영속성 컨텍스트에 저장되었다가 분리된 상태

- 삭제 (removed): 삭제된 상태 

 

 

말만해서는 이해가 안될것 같으니 코드로 생각해보자.

비영속

// 객체를 생성한 상태 (비영속)
Member member = new Member();
member.setId("member1");
member.setName("member1");

객체를 생성했지만 영속성 컨텍스트에는 전혀 관계가 없는 상태이다. 영속성 컨텍스트에 담는 코드는 없기 때문에.

위에서 영속성 컨텍스트는 곧 엔티티 매니저와 1:1 매핑이 된다고 했는데 엔티티 매니저를 영속성 컨텍스트라고 생각해보자.

그럼 아래와 같은 이미지로 볼 수 있는 것이다.

 

영속

// 객체를 생성한 상태 (비영속)
Member member = new Member();
member.setId("member1");
member.setName("member1");

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

// 객체를 저장한 상태 (영속)
em.persist(member);

영속은 이제 엔티티 매니저에 담는것이라고 보면 된다. 어디서 많이 본 메서드인 persist()가 보인다. 이 메소드를 호출해서 멤버를 담는게 바로 아래와 같은 그림이 되는것이다.

⭐️ 그러니까 결국 persist() 메서드는 데이터베이스에 저장하는게 아니다. 영속성 컨텍스트에 영속시키는 것이다. 이 코드만으로 데이터베이스에 절대 절대 저장되지 않는다.

그럼 이 전 파트에서는 persist() 메서드를 호출하고 CREATE 부분을 끝냈는데 어디서 데이터베이스에 저장되는 걸까?

바로 트랜잭션의 커밋이다. 트랜잭션 커밋을 수행하면 쓰기 지연 SQL문이 실행되어 데이터베이스에 실제로 데이터가 저장된다.

 

못 믿겠다면 실제 코드를 수행해보자.

package org.example;

import org.example.entity.Member;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.EntityTransaction;
import javax.persistence.Persistence;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        // ! EntityManagerFactory 이 녀석은 서비스가 띄워지면 딱 한개만 생성되어야 한다.
        EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");

        // ! EntityManager 이 녀석은 어떤 디비에 작업을 할 때마다 하나씩 만들어지고 작업이 끝나면 버려져야 한다.
        EntityManager em = emf.createEntityManager();
        // ! 모든 데이터베이스에 대한 변경 작업은 트랜잭션 안에서 일어나야 한다. (조회는 꼭 트랜잭션 안에서가 아니더라도 상관없다)
        // ! 하나의 트랜잭션에서 원하는 작업을 끝내고 그 트랜잭션안에서 커밋을 해줘야 변경이 적용된다.
        EntityTransaction tx = em.getTransaction();

        // ! Transaction 시작
        tx.begin();

        try {
            /* CREATE */
            Member member = new Member();
            member.setName("helloD");
            em.persist(member);

            //tx.commit();
        } catch (Exception e) {
            tx.rollback();
        } finally {
            em.close();
            emf.close();
        }
    }
}

위 코드처럼 persist() 메서드 호출 후 트랜잭션 커밋을 주석처리 해보자. 실행한 후 실제 데이터베이스에 helloD 라는 이름을 가지는 멤버가 있는지 보자.

없다. 즉, persist() 메서드는 영속 컨텍스트에 저장하는 메서드이지 데이터베이스에 저장하는 메서드가 아니다. 반드시 이 개념을 이해해야 한다. 그리고 또한, 데이터베이스에서 조회할 때도 영속 컨텍스트에 조회한 데이터도 영속된다. 

// 영속 컨텍스트에 영속시킴
Member member = em.find(Member.class, 1L);

이처럼 데이터베이스를 통해 조회를 할 때, 해당 데이터를 조회한 후 영속 컨텍스트에 영속시킨다. 그니까 영속되는 경우는 크게 두가지인거지. 데이터베이스로부터 조회한 경우와 persist() 메서드를 호출해서 영속시킨 경우.

 

준영속, 삭제

// 회원 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
em.detach(member);

// 객체를 삭제한 상태 (삭제)
em.remove(member);

준영속은 꽤 중요한데 영속된 객체를 비영속으로 변경하는 경우를 말한다.

예를 들어, 데이터베이스를 통해 조회한 객체는 영속된다고 했는데 그 영속된 데이터를 영속 컨텍스트에서 관리할 필요가 없는 경우 준영속으로 변경할 수 있다. 

// 영속 컨텍스트에 영속시킴
Member member = em.find(Member.class, 1L);

// 영속 컨텍스트에서 제외시킴
em.detach(member);

위 코드를 보면 memberdetach() 메서드가 호출된 후 더이상 영속 컨텍스트가 관리하지 않는다.

이를 눈으로 확인해보기 위해선, 꺼낸 데이터를 변경한 후에 커밋하기 전 detach()를 호출해보면 알 수 있다.

// 영속 컨텍스트에 영속시킴
Member member = em.find(Member.class, 1L);

member.setName("BBB");

// 영속 컨텍스트에서 제외시킴
em.detach(member);

// 아무일도 일어나지 않음
tx.commit();

커밋하기 전 영속 컨텍스트에서 제외시켰으므로, setName()을 호출해서 이름을 변경해도 데이터베이스에 적용되지 않는다.

 

준영속으로 변경하는 방법은 크게 세 가지가 있는데, 한 가지는 위처럼 detach() 메서드를 호출하거나 clear() 메서드를 호출하거나 아예 엔티티 매니저를 닫는것이다.

em.detach(member); // 특정 엔티티를 준영속으로 변경
em.clear(); // 영속 컨텍스트를 완전 초기화
em.close(); // 영속 컨텍스트를 종료

 

영속성 컨텍스트의 이점

  • 1차 캐시
  • 동일성(identity) 보장
  • 트랜잭션을 지원하는 쓰기 지연
  • 변경 감지(Dirty Checking)
  • 지연 로딩(Lazy Loading)

 

 

1차 캐시

1차 캐시란, 영속 컨텍스트에 객체가 영속이 되면 그 객체를 가져올 때 데이터베이스로부터 조회하는 것이 아니라 영속 컨텍스트로부터 가져오는 기술을 말한다. 물론, 이 1차 캐시가 큰 의미가 있진 않은데 그 이유는 위에서도 말했지만 영속 컨텍스트는 엔티티 매니저와 1:1로 매핑된다고 했다. 즉, 엔티티 매니저가 닫히는 순간 1차 캐시도 의미가 없어지기 때문에 비즈니스 로직이 정말 정말 복잡해서 하나의 트랜잭션에서 여러번 같은 객체가 사용되거나 호출될 때만 의미가 있지 그렇지 않고서는 큰 의미는 없다만 그래도 알고 있어야 한다. 

 

// 엔티티 생성한 상태 (비영속)
Member member = new Member();
member.setId("member1");
member.setName("member1");

// 엔티티 영속
em.persist(member);

이렇게 영속 시킨 후 영속 컨텍스트에 1차 캐시에 해당 엔티티(객체)가 담긴다. 그렇게 담긴 이후에 해당 객체를 다시 조회하는 코드를 마주치면 데이터베이스로부터 객체를 조회하지 않고 1차 캐시에서 꺼내올 수 있다. 

// 엔티티 생성한 상태 (비영속)
Member member = new Member();
member.setId("member1");
member.setName("member1");

// 엔티티 영속 -> 1차 캐시에 저장됨 
em.persist(member);

// 1차 캐시에서 조회
Member findMember = em.find(Member.class, "member1");

 

그런데 이제 만약 위 사진처럼 "member1" 이라는 객체만 1차 캐시에 담겨있는 상태에서 "member2"를 조회하고자 한다면, 1차 캐시에 없기 때문에 데이터베이스에서 조회한다. 

Member findMember2 = em.find(Member.class, "member2");

 

동일성 보장

영속 컨텍스트에서 꺼내온 객체는 동일함을 보장한다는 뜻이다. 즉, 아예 같은 인스턴스이고 같은 메모리 주소값을 가지는 것을 보장한다.

Member findMember1 = em.find(Member.class, "member2");
Member findMember2 = em.find(Member.class, "member2");

System.out.println(findMember1 == findMember2) // true

 

 

트랜잭션을 지원하는 쓰기 지연

이는 트랜잭션 안에서 수행되는 모든 데이터베이스에 대한 변경 작업을 수행하기 위한 SQL문을 트랜잭션의 커밋이 호출되기 전까지 데이터베이스에 보내지 않고 모아둔 상태에서 커밋을 호출하는 순간 모아둔 SQL문을 보낸다는 뜻이다.

 

즉, 만약 내가 새로운 멤버를 두 명 만든다고 가정해보자.

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();

// 트랜잭션 시작
transaction.begin();

em.persist(memberA);
em.persist(memberB);
// 여기까지가 영속 컨텍스트에 memberA, memberB를 영속시키고 INSERT SQL문을 쓰기 지연 보관소에 저장한다.
// 허나, 데이터베이스에 보내지는 않는 상태이다.

// 트랜잭션 커밋
// 이 순간에 데이터베이스에 INSERT SQL문을 보낸다.
transaction.commit()

 

그래서 이 코드를 그림으로 살펴보면 다음과 같다.

 

persist() 메서드는 영속 컨텍스트에 객체를 저장. 그리고 저장과 동시에 INSERT SQL문을 쓰기 지연 저장소에 저장한다.

 

이 때까지는 데이터베이스에 해당 객체를 저장하지 않은 상태. 즉, SQL 쿼리도 날라가지 않은 상태.

그리고 트랜잭션 커밋이 호출되는 순간 쓰기 지연 SQL 저장소에 모아둔 쿼리문이 실행된다. 

이 부분에서 persistence.xml 파일에 속성으로 있던 batch_size가 이 내용과 관련이 있다. 한번에 보낼 수 있는 사이즈를 지정하는 속성값.

 

 

변경 감지(Dirty Checking)

업데이트를 할 때 업데이트한 후 뭔가 업데이트를 실행하는 코드가 있어야 할 것 같은데 없었다. 그럼 persist() 메서드라도 호출해야 할까? 그것도 아니다 왜냐하면 이제 우리는 안다. persist() 메서드는 영속 컨텍스트에 영속시키는 것일 뿐인걸. 즉, 이미 영속된 객체를 또 영속시킨다는 코드를 작성할 필요가 없단 말이다. 그럼 어떻게 업데이트한 걸 알까? 

 

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();

transaction.begin();

Member memberA = em.find(Member.class, "memberA");
memberA.setName("Changed");

transaction.commit()

자, 이런 코드가 있고 이게 정말 업데이트의 끝이다. 근데 바꾸고 아무것도 안하고 커밋만 했단 말이지? 어떻게 변경 사항을 적용할까? 

사실 영속 컨텍스트에는 스냅샷 데이터가 존재한다.

 

그래서 객체와 스냅샷을 비교해서 값이 다르면 SQL 문을 수행하게 되는것이다. 

위 그림에서 flush()가 들어오면 엔티티와 스냅샷이 존재하는데 그 값을 비교한다. 비교 후 값이 다르다면 다른 값을 적용하기 위해 UPDATE SQL문을 생성해서 수행하게 되는것이다.

 

플러시란?

플러시란 변경, 수정, 삭제와 같은 데이터베이스의 데이터와 영속 컨텍스트의 데이터가 달라진 경우 데이터베이스에 달라지는 값을 맞춰주는 작업이다. 즉, 쉽게 말해 쓰기 지연 SQL 저장소의 쿼리가 데이터베이스에 날라가는 것이라고 보면 되는데 이 플러시를 호출하는 방법은 크게 세 가지가 있다. 

 

- em.flush(): 직접 호출

- 트랜잭션 커밋: 자동 호출

- JPQL 쿼리 실행: 자동 호출

 

플러시를 한다고해서 영속 컨텍스트에 데이터를 지운다거나 1차 캐시에 데이터를 지우는게 아니고 그냥 쓰기 지연 SQL 저장소의 쿼리가 날라가는 것 뿐이다.

 

 

728x90
반응형
LIST
728x90
반응형
SMALL
SMALL

2024.10.24일 업데이트


 

JPA를 진짜 깊게 이해하기 위해 아예 순수 JPA 세팅부터 시작해 보려고 한다. 내가 처음 JPA를 사용했을 때 느꼈던 것보다 훨씬 진짜 훨씬 더 많은 내용이 JPA에 있었는데 지금이라도 깊게 공부하게 되서 다행인거 같다.

 

우선 프로젝트를 Maven 기반으로 시작해보자.

 

pom.xml

현재 정말 아무것도 없는 상태에서 pom.xml 파일 하나만 있는 상태다. 이 파일에서 필요한 두 가지가 있는데 하나는 hibernate, 하나는 h2database다.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>hello-jpa</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>18</maven.compiler.source>
        <maven.compiler.target>18</maven.compiler.target>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-entitymanager</artifactId>
            <version>5.6.15.Final</version>
        </dependency>

        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <version>2.2.224</version>
        </dependency>
    </dependencies>

</project>

딱 두개의 Dependency가 있다. 내려받고 나면 우측 MavenDependencies 섹션에 두 개가 노출된다.

 

persistence.xml

이제 JPA를 사용하기 위해 persistence.xml 파일이 필요하다. 설정 파일이라고 생각하면 되는데 사실 거의 JPA를 사용할 때 스프링과 연동하여 사용하기 때문에 xml 파일로 설정값을 지정하지 않는데 정말 뿌리부터 시작해보기 위해 해보려고한다.

 

persistence.xml 파일은 경로가 중요하다. 이 파일은 반드시 META-INF 폴더 아래에 존재해야 한다. 그래서 내 경로는 다음과 같다.

resources/META-INF/persistence.xml  이 경로에 해당 파일이 존재하면 된다. 이 파일은 다음과 같은 설정 파일이 필요하다.

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.2"
             xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_2.xsd">
    <persistence-unit name="hello">
        <properties>
            <!-- 필수 속성 -->
            <property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
            <property name="javax.persistence.jdbc.user" value="sa"/>
            <property name="javax.persistence.jdbc.password" value=""/>
            <property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/h2/test"/>
            <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
            <!-- 옵션 -->
            <property name="hibernate.show_sql" value="true"/>
            <property name="hibernate.format_sql" value="true"/>
            <property name="hibernate.use_sql_comments" value="true"/>
            <property name="hibernate.jdbc.batch_size" value="10"/>
<!--            <property name="hibernate.hbm2ddl.auto" value="create-drop" />-->
        </properties>
    </persistence-unit>
</persistence>

persistence-unit name은 나중에 Persistence에서 EntityManagetFactory를 만들 때 필요한 값이다. 저 값을 통해 어떤 설정값을 가져올지를 지정한다. 나머지 속성값은 어떤 데이터베이스를 사용할지 나는 h2database를 사용할거고, 데이터베이스 접속할 유저정보데이터베이스의 위치정보 그리고 dialect 정보를 지정한다.

 

dialect가 재밌는 옵션인데, 데이터베이스마다 살짝 살짝 다른식으로 표현하는 것을 본적이 있을거다. 예를 들면, MySQL은 VARCHAR Oracle은 VARCHAR2라던가, MySQL은 LIMIT, Oracle은 ROWNUM이라던가. 이런걸 데이터베이스 방언이라고 표현하는데 이 방언을 어떤걸 선택할건지를 지정하는 옵션이라고 보면 된다. 나는 H2를 사용하니까 당연히 H2Dialect를 사용하면 된다.

 

show_sql은 데이터베이스에 날리는 쿼리를 보여줄것인지 여부를 의미한다. format_sqlshow_sqltrue인 경우에 한하여 SQL문을 정렬해서 좀 보기 좋게 보여주겠다는 옵션이고, use_sql_commentsshow_sqltrue인 경우에 한하여 SQL문에 주석 데이터를 추가해주는 옵션이다. 그러니까 이게 어떤 SQL문인지 뭐 그런 comments를 보여주는 옵션. batch_size는 이후에 또 배우겠지만 쓰기 지연 SQL 쿼리를 한번에 날릴 수 있는 사이즈를 지정하는 것이다. 이건 이후에 영속성 컨텍스트를 얘기하면서 다시 얘기하겠다.

 

이렇게 설정해놓으면 필요한 설정 파일은 전부 구성했고 이제 실제 코드를 작성해보자. 

 

Member

package org.example.entity;

import javax.persistence.*;

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

    @Column(unique = true, nullable = false, length = 50)
    private String name;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

Member라는 간단한 엔티티는 id, name 컬럼을 가진다. 이 클래스의 @Entity 어노테이션을 붙이면 JPA는 해당 클래스를 테이블로 매핑한다. 이렇게 클래스를 엔티티로 구현하고 h2database에 테이블로 만드는 방법은 persistence.xml 파일의 프로퍼티 중 ddl-autocreate으로 설정하거나, 직접 h2database에 들어가서 테이블을 만들면 된다. 

 

아 그리고 한가지 짚고 넘어갈 내용은 이 아래 @Column에 적힌 unique, nullable, length 이런 제약 조건은 데이터베이스 테이블에 영향을 주는거고 애플리케이션에는 아무런 영향이 없다는 것. 그러니까 객체로 만들고 데이터베이스에 저장하지 않으면 객체가 같은 이름을 가지던 길이가 50이 초과되던 상관없단 소리다.

@Column(unique = true, nullable = false, length = 50)

H2Database

우선 H2Database Engine을 다운받아야 한다. 

https://www.h2database.com/html/main.html

 

H2 Database Engine

H2 Database Engine Welcome to H2, the Java SQL database. The main features of H2 are: Very fast, open source, JDBC API Embedded and server modes; in-memory databases Browser based Console application Small footprint: around 2.5 MB jar file size     Supp

www.h2database.com

위 경로에서 Download 받으면 된다.

 

2.2.224 버전을 사용하게 되면 자동으로 데이터베이스를 만들어주지 않는다. 그래서 데이터베이스를 직접 만들어야 하는데, 나같은 경우엔 데이터베이스 경로를 /Users/cw.choiit/h2 이렇게 설정했다. 여기에 데이터베이스명은 'test'라고 할 것이기 때문에 해당 경로에 파일 하나를 추가하면 된다. 'test.mv.db' 이 파일 하나만 추가해주면 H2database를 실행하고 콘솔에서 연결할 수 있다.

H2database를 로컬에서 실행하면 위 경로에 들어가서 콘솔을 이용할 수 있는데 여기서 원하는 경로에 데이터베이스를 연결하고 'Connect' 버튼을 클릭하면 데이터베이스 안으로 들어갈 수 있다.

 

Main

package org.example;

import org.example.entity.Member;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.EntityTransaction;
import javax.persistence.Persistence;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        // ! EntityManagerFactory 이 녀석은 서비스가 띄워지면 딱 한개만 생성되어야 한다.
        EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");

        // ! EntityManager 이 녀석은 어떤 디비에 작업을 할 때마다 하나씩 만들어지고 작업이 끝나면 버려져야 한다.
        EntityManager em = emf.createEntityManager();
        // ! 모든 데이터베이스에 대한 변경 작업은 트랜잭션 안에서 일어나야 한다. (조회는 꼭 트랜잭션 안에서가 아니더라도 상관없다)
        // ! 하나의 트랜잭션에서 원하는 작업을 끝내고 그 트랜잭션안에서 커밋을 해줘야 변경이 적용된다.
        EntityTransaction tx = em.getTransaction();

        // ! Transaction 시작
        tx.begin();

        try {
            /* CREATE */
            /*Member member = new Member();
            member.setName("helloA");
            em.persist(member);*/

            /* READ */
            /*Member member = em.find(Member.class, 1L);
            System.out.println("member ID = " + member.getId());
            System.out.println("member Name = " + member.getName());*/

            /* UPDATE */
            // ! Update 에서는 persist() 호출하지 않아도 상관없이 그냥 변경할 거 변경하고 트랜잭션을 commit() 해주면 된다.
            // ! 그 이유는 JPA 이 녀석이 데이터베이스의 데이터를 컬렉션처럼 다루기 때문
            /*Member member = em.find(Member.class, 1L);
            member.setName("HelloB");*/

            /* DELETE */
            /*Member member = em.find(Member.class, 1L);
            em.remove(member);*/

            /* Entity 객체를 대상으로 쿼리를 날릴 수 있는 JPQL 이라는 녀석을 사용 / SQL 은 테이블을 대상으로 날리는 것 */
            List<Member> result = em.createQuery("select m from Member m", Member.class).getResultList();
            for (Member member : result) {
                System.out.println("member = " + member.getName());
            }

            tx.commit();
        } catch (Exception e) {
            tx.rollback();
        } finally {
            em.close();
            emf.close();
        }
    }
}

위 코드에서 간단한 CRUD를 실행해보았다. 한 줄 한 줄 이해해보자.

 

Persistence 클래스의 createEntityManagerFactory() 메소드를 호출하고 해당 메소드에 'hello' 라는 값을 지정한다. 이 값은 persistence.xml 파일에 name으로 지정한 값이다. 해당 속성값을 불러오겠다는 의미가 된다.

 

이제 팩토리에서 엔티티 매니저를 생성한다. 이 엔티티 매니저는 고객의 요청에 의해 필요한 데이터베이스 작업을 할 때 트랜잭션이라는 단위를 생성해내는데 고객의 요청 하나에 하나의 트랜잭션이 사용된다고 생각하면 된다. 즉, 요청 하나에 엔티티 매니저 하나가 생성된다는 뜻이다. 요청에 의해 필요한 작업이 다 끝나면 엔티티매니저는 종료되어야 한다. 커넥션 풀에 한계가 있기 때문에 잡고 있는 커넥션을 놓아준다고 생각하면 된다.

 

그렇게 엔티티 매니저가 생성되면, 엔티티 매니저로부터 트랜잭션을 가져올 수 있다. 이 트랜잭션을 가져와 시작하게 되면 이 때부터 모든 데이터 베이스의 변경 작업을 진행할 수 있게된다. 어떤 데이터베이스든 모든 데이터베이스의 대한 작업은 트랜잭션이라는 단위 안에서 일어난다.

 

CREATE

멤버를 생성하는 방법은 정말 간단하게 새로운 멤버 객체를 만들고 필요한 데이터를 추가한 후 엔티티매니저의 persist() 메소드에 만든 멤버를 추가해주면 된다. 그럼 끝이다.

 

READ

조회는 엔티티매니저의 find() 메소드를 호출한다. 여기서 원하는 객체 타입과 PK 정보를 던져주면 엔티티매니저가 데이터베이스에서 알맞은 데이터를 찾아낸다. 

 

UPDATE

데이터를 수정하는 방법은 조회한 후 해당 데이터를 변경해주기만 하면 된다. 이러고 persist() 메소드를 호출하지도 않는다. 이를 제대로 이해하려면 영속성 컨텍스트를 알아야 하는데 다음 파트에서 알아 볼 예정이다. 그러니까 쉽게 생각해서 자바에서 컬렉션을 다룰 때 컬렉션의 데이터를 꺼내 데이터를 변경하면 그 데이터를 다시 컬렉션에 추가하지 않는것처럼 똑같은 방식으로 동작한다고 생각해보자.

 

DELETE

엔티티매니저로부터 remove() 메소드를 호출하면 끝.

 

JPQL

그리고 엔티티매니저가 제공하는 기본 메소드 말고도 JPQL을 사용할 수 있는데 JPQLSQL과 유사하나, SQL은 테이블을 대상으로 한 쿼리이고 JPQL은 객체를 대상으로 하는 쿼리이다. 즉 JPQL을 통해 데이터를 객체로 가져온다고 생각하면 된다. 

 

 

트랜잭션 커밋

이렇게 모든 작업이 트랜잭션안에서 이루어지면 트랜잭션의 커밋을 반드시 해줘야한다. 커밋을 하지 않으면 데이터베이스에 변경 작업은 단 하나도 이루어지지 않는다. 그리고 커밋이 행해지기 전 어떤 오류가 있다면 트랜잭션 안에서 작업한 모든 작업을 롤백하는 트랜잭션 롤백이 있다. 다시 한 번 말하지만 모든 데이터베이스는 항상 트랜잭션이라는 단위안에서 데이터베이스에 대한 작업이 이루어진다.

 

 

이렇게 모든 작업을 끝내면 엔티티 매니저를 닫고, 엔티티 매니저 팩토리를 닫는다. 엔티티 매니저는 커넥션을 반납하는 개념이고 엔티티매니저 팩토리는 서비스가 종료될 때 닫으면 된다. 또한 서비스가 띄워질 때 딱 한 번만 생성된다. 

 

728x90
반응형
LIST
728x90
반응형
SMALL
SMALL

Hibernate는 자바 기반의 오픈소스 프레임워크로 객체 지향된 도메인 모델과 RDB 사이의 연결을 제공한다. Hibernate가 자바 애플리케이션에서 데이터베이스 관련 프로그래밍을 개발자들이 Java Objects를 통해 할 수 있도록 도와준다. 복잡한 SQL 쿼리 대신. 

 

Hibernate의 핵심 특징은 다음과 같다. 

 

1. Object-Relational Mapping (ORM): Hibernate의 핵심 목적은 객체 지향적 언어와 RDB 사이의 갭에 연결 다리를 놓는것이다. 그리고 그를 위해 양방향으로 자바 오브젝트들과 데이터베이스 테이블들 사이를 매핑해준다. 

 

2. Persistence: Hibernate는 RDB에 또는 RDB로부터 자바 오브젝트들을 저장하거나 읽어오는 메커니즘을 제공한다. Hibernate는 low-level SQL을 사용해 상호작용하는 방식을 추상화하여 개발자들이 데이터베이스와 직접적으로 상호작용하는게 아닌 자바 오브젝트들을 가지고 작업할 수 있게 도와준다.

 

3. Hibernate Configuration: Hibernate를 사용하기 위해, Java-based configuration file(application.yml or application.properties)을 통해 설정이 필요한데 이런 설정 파일은 데이터베이스 접속 정보를 포함한 여러 설정 정보들을 명세할 수 있다. 

 

4. Hibernate Mapping: Hibernate는 metadata(XML or Annotation)를 사용해서 자바 클래스들과 데이터베이스 테이블들에 대한 매핑을 정의한다. 이런 매핑들은 자바 오브젝트들의 필드나 속성들이 어떻게 데이터베이스의 컬럼과 상응하는지를 구체화한다. 
(예: @Id, @Column(nullable = false, length =50, unique = true))

 

5. Session and Session Factory: Hibernate는 세션 기반의 모델에서 동작한다. 하나의 세션은 하나의 단일 데이터베이스 커넥션에 상응하고 작업한다. 세션 팩토리는 세션을 생성하고 관리한다. 꽤나 무겁고 Thread-safe objects 형태이며 일반적으로 애플리케이션이 시작될 때 한 번 만들어진다.

 

6. HQL(Hibernate Query Language): Hibernate는 본인만의 언어인 HQL을 제공한다. SQL과 유사하나 자바 오브젝트로 동작한다. HQL은 개발자들이 데이터베이스에 대한 쿼리를 객체 지향형 문법으로 사용할 수 있게 해준다. 

 

7. Caching: Hibernate는 캐싱 메커니즘을 지원하는데, 이것이 애플리케이션의 퍼포먼스를 향상시킨다. 메모리에서 오브젝트들의 캐시를 할 수 있으며 이는 곧 많은 수의 데이터베이스 쿼리들을 절감시켜준다.

 

8. Lazy Loading: Hibernate는 개발자들로 하여금 lazy loading 구성을 할 수 있게 해주는데 그 데이터들이 실제로 액세스될 때만 오브젝트들이 데이터베이스로부터 로드된다. 이는 퍼포먼스 최적화에 도움을 준다.

 

9. Transactions: Hibernate는 데이터베이스 트랜잭션을 지원하고 다양한 트랜잭션 관리 시스템을 통합할 수 있게 해준다. 

 

Hibernate는 흔히 Java enterprise application에서 사용되고 효율적인 방식으로 데이터베이스 상호작용을 관리한다. 반복적인 SQL 코드들을 줄여주고, 데이터베이스 스키마의 변화를 단순화시킨다. 

 

 

Hibernate와 JPA의 차이

Hibernate과 JPA는 연관성이 있으나 가장 큰 차이점은 JPA는 명세 또는 API라는 점이다. 즉, 표준 인터페이스(또는 어노테이션)를 정의한다. 반면 Hibernate는 유명하며 완성된 ORM 프레임워크이다. 그리고 이 프레임워크는 JPA 명세를 구현했다. JPA의 구현체가 Hibernate이라고 생각하면 되지만 JPA 명세를 넘어서서 추가적인 특징들도 가지고 있는게 Hibernate이다.

 

요약하자면, JPA는 표준화된 API로 여러 ORM 프레임워크들이 구현할 수 있다. 이 JPA가 공통된 규칙들의 셋과 어노테이션을 제공한다. Hibernate는 JPA의 구체적인 구현체다. 

728x90
반응형
LIST
728x90
반응형
SMALL
SMALL

JPA는 Java Persistence API의 약자로, RDB와 Java Objects 간 데이터 접근, 관리, 지속성에 대한 명세라고 생각하면 된다.

좀 더 간단하게는 Relational Database와 Java application이 상호작용하게 도움을 주는 녀석이라고 생각하자.

 

JPA의 핵심은 다음과 같다.

 

1. Object-Relational Mapping (ORM): JPA는 자바 오브젝트들과 데이터베이스 테이블을 양방향으로 매핑해 주는 방법을 제공한다. 이는 개발자들에게 코드상에서 자바 오브젝트들을 가지고 데이터베이스의 데이터들을 핸들링할 수 있게 한다.

 

2. Entity Classes: JPA는 엔티티 클래스를 정의할 수 있게 해주는데 엔티티 클래스라 함은 데이터베이스에 저장하고 싶은 데이터들을 또는 칼럼을 나타낸다. 이런 클래스들은 일반적으로 JPA 어노테이션들을 사용하여 데이터베이스를 구체화한다.
(예: @Table(name = "users"), @Entity 등)

 

3. EntityManager: 엔티티 매니저는 JPA에서 핵심이 되는 인터페이스인데, 엔티티들을 관리하는데 사용된다. EntityManager는 CRUD에 대한 메서드들을 제공하며 JPQL(Java Persistence Query Language)를 사용해서 데이터베이스에 대한 쿼리를 수행할 수도 있다. 이 EntityManager는 하나의 트랜잭션에 하나가 쓰이게 된다. 즉, 고객의 요청에 의해 어떤 데이터베이스에 대한 작업을 하기 위해 트랜잭션이 시작된 후 모든 데이터베이스에 대한 작업이 끝나면 트랜잭션을 커밋하면 데이터베이스에 작업이 반영된다. 그 후 엔티티 매니저는 닫혀야한다.

 

4. JPQL(Java Persistence Query Language): JPQL은 SQL과 유사하나, JPA 엔티티와 이용될 수 있도록 설계되었다. JPQL을 사용해서 객체지향 방식으로 데이터베이스 쿼리를 수행할 수 있고 데이터를 가져올 수 있다.

 

5. Persistence Unit: Persistence Unit은 설정과 관련이 있고 이는 어떻게 JPA가 Java Application 내에서 사용되는지를 정의한다. data source, entity classes, 또는 다른 JPA와 관련된 세팅들을 명세한 설정이라고 생각하면 된다. 

 

6. Transaction Management: JPA는 트랜잭션 관리를 지원하는데 트랜잭션 관리란 데이터베이스에 변화가 생겼을 때 그에 대한 지속성 또는 업데이트 처리를 말한다. 어노테이션을 사용하거나 코드 기반의 메서드를 통해 트랜잭션을 정의하고 관리할 수 있다.

 

JPA를 사용하므로써, 자바 개발자는 데이터베이스와 연관된 작업을 좀 더 객체 지향적으로, 표준화된 방식으로 작업할 수 있다. 

728x90
반응형
LIST

+ Recent posts