패러다임 불일치

애플리케이션은 자바라는 객체지향 언어로 개발하고 데이터는 관계형 데이터베이스에 저장해야 한다면, 패러다임의 불일치 문제를 개발자가 중간에서 해결해야 한다.

객체는 상속 이라는 개념을 가지고 있지만 테이블은 상속이라는 기능이 없으며 이를 해결하기 위해서 슈퍼타입 서브타입 관계를 사용하여 객체 상속와 유사한 형태로 테이블 설계가 가능 하다.

JDBC API 를 사용해서 Album, Movie 객체를 저장하는 코드를 완성하기 위해서는 각 객체를 저장하는 SQL 을 생성해야 하며 이때, Item 테이블 저장 쿼리도 개발이 필요하다.

조회의 경우, Album 을 조회하기 위해서는 Item 과 Album 테이블을 조인해서 조회하고 그 결과로 Album 객체를 생성해야 한다.

이런 과정이 패러다임 불일치 해결을 위해 소모하는 비용이다. 만약 해당 객체들을 DB 가 아닌 자바 컬렉션에 보관한다면 부모 자식 관계 고려하지 않고 해당 컬렉션을 사용 하면 된다.

이런 비용을 JPA 에서 해결해 준다.

JPA 에서 제공되는 “persist()” 메소드를 사용하여 객체를 저장하면 JPA 는 ITEM, ALBUM 에 INSERT 하는 쿼리를 실행하고 두 테이블에 저장해 준다.

jpa.persist(album);

객체 조회의 경우 “find()” 메소드를 사용하여 ALBUM 테이블을 조회할 경우 JPA 는 ITEM 과 ALBUM 테이블을 조인해서 그 결과를 반환해 준다.

Album album = jpa.find(Album.class, albumId);

객체와 테이블 차이

테이블에 맞춘 객체 모델.

참조를 사용하는 객체 모델.

테이블에 맞춘 객체 모델처럼 외래 키까지 관계형 데이터베이스 방식에 맞추면 Member 객체와 연관된 Team 객체를 참조를 통해서 조회할 수 없다. 또한 객체지향의 특징도 잃어버리게 된다.

위 두가지 모델의 차이는 객체 모델의 경우 외래키가 필요 없고 참조만 있으면 되지만 테이블은 참조가 필요 없고 외래 키만 있으면 된다. 두 패러다임의 차이를 개발자가 중간에서 변환하는 역할을 해줘야 한다.

영속성 (1)

엔티티의 생명주기

비영속 : 영속성 컨텍스트와 전혀 관계가 없는 상태.

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

영속 : 영속성 컨텍스트에 저장된 상태

//객체를 저장한 상태(영속), 영속성 컨텍스트에 의해 관리 된다는 뜻
em.persist(member);

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

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

삭제 : 삭제된 상태

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

엔티티 조회

영속성 컨텍스트가 엔티티를 관리하며 얻는 장점

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

1차 캐시

엔티티를 영속 하기위해서 “em.persist(member);” 를 실행하면 1차 캐시에 회원 엔티티를 저장한다. 이때 회원 엔티티는 아직 데이터베이스에 저장되지 않았다.

1차 캐시의 키는 식별자 값이다.

식별자 값은 DB기본 키와 매핑 되어 있다.

em.find() 를 호출하면 먼저 1차 캐시에서 엔티티를 찾고 만약 찾는 엔티티가 1차 캐시에 없으면 DB 에서 조회한다. 그리고 1차 캐시에 저장후에 영속 상태의 엔티티를 반환하게 된다.

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

//1차캐시에저장됨
em.persist(member);

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

엔티티 인스턴스가 1차 캐시에 존재하게 되므로 해당 엔티티를 조회하면 메모리에서 바로 불러오게 되어 성능상 이점도 누릴 수 있다.

엔티티 동일성 보장

아래 보기에서 a == b 는 참일까? 거짓일까?

Member a = em.find(Member.class, "memberl");
Member b = em.find(Member. class, "memberl");
System.out.println(a == b); //동일생 비교

위와같이 반복하여 호출해도 영속성 컨택스트는 1차 캐시의 같은 인스턴스를 반환하고 당연히 결과는 참이다.

쓰기지연

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
//엔티티 매니저는 데이터 변경 시 트랜잭션을 시작해야 한다 
transaction.begin (); // [트랜잭션] 시작

em.persist(memberA);
em.persist(memberB); 
//여기까지 INSERT SQL을 데이터베이스에 보내지 않는다

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

엔티티 매니저는 트랜잭션을 커밋하기 직전까지 DB 에 엔티티를 저장하지 않고 내부 쿼리 저장소에 INSERT SQL 을 모아둔다. 그리고 트랜잭션 커밋이 발생하면 모아둔 쿼리를 한번에 DB 에 보내며 이것을 트랜젝션을 지원하는 쓰기 지연 이라고 한다.

트랜젝션을 지원하는 쓰기 지연이 가능한 이유

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

save (A);
save (B);
save (C);

commit(); //트랜잭션 커밋

데이터를 저장 하는 즉시 등록 쿼리를 데이터베이스에 보낸다. 위에서 save() 메소표를 호출할 때마다 즉시 데이터베이스에 등록 쿼리를 보낸다. 그리고 마지막에 트랜잭션을 커밋한다.
데이터를 저쟁하면 등록 쿼리를 데이터베이스에 보내지 않고 메모리에 모아 둔다. 그리고 트랜잭션을 커밋할 때 모아둔 등록 쿼리를 데이터베이스에 보낸 후에 커밋한다.

변경감지(dirty checking)

JPA 로 엔티티를 수정할 때는 단순히 엔티티를 조회해서 데이터만 변경하면 된다. 트랜젝션 직전에 em.update() 메소드를 실행해야 할 것 같지만 엔티티 변경사항은 DB 에 자동으로 반영되며 이것을 변경감지 라고 한다.

트랜잭션을 커밋하면 엔티티 매니저 내부에서 먼저 플러시(flush())가 호출 된다.
엔티티와 스넵샷을 비교해서 변경된 엔티티를 찾는다.
변경된 엔티티가 있으면 수정 쿼리를 생성해서 쓰기 지연 SQL 저장소에 보낸다
쓰기 지연 저장소의 SQL을 데이터베이스에 보낸다
DB에 트랜잭션을 커밋한다.

JPA 엔티티 업데이트 전략의 장점

JPA 는 기본전략으로 엔티티의 모든 필드를 업데이트 한다.
모든 필드를 사용하면 수정 쿼리가 항상 같으므로 재사용 가능
데이터 베이스에 동일 쿼리를 보내므로 이전에 파싱된 쿼리 재사용 가능

to be continue…

Back

JPA(패러다임불일치, 영속성)