1. JPA
Java Persistence API 로 자바 진영의 ORM 기술 표준이다.
SQL 중심적인 개발에서 객체 중심으로 개발할 수 있다.
또한 JPA는 하이버네이트, EclipseLink, DataNucleus 3가지 인터페이스의 구현체이다.
1-1 JPA CRUD
jpa.persist(member): 저장Member member = jpa.find(memberId): 조회member.setName("updataName"): 수정 (update의 동작원리 중요!)jpa.remove(member): 삭제
1-2 JPA의 성능 최적화 기능
-
1차 캐시와 동일성(identity) 보장: 같은 트랜잭션 안에서는 같은 엔티티를 반환한다. 같은 트랜잭션안에서==이 가능하다. -
트랜잭션을 지원하는 쓰기 지연 (transactional write-behind): 트랜잭션을 커밋할 때까지 SQL을 데이터베이스에 보내지 않는다. 이러한 특징을 이용해서 성능을 최적화할 수 있다. -
지연 로딩(Lazy Loading): 객체가 실제 사용될 때 로딩한다. 반대로 즉시 로딩은 JOIN SQL로 한번에 연관된 객체까지 미리 조회한다. 서로 연관된 객체가 많을 경우에 지연로딩을 꼭! 이용해야 한다.
2. ORM object-relational mapping (객체 관계 매핑)
객체는 객체대로 설계하고 관계형 데이터베이스는 관계형 데이터베이스로 설계하고 ORM 프레임워크가 중간에서 매핑하는 것이다.
대중적인 언어에는 대부분 ORM 기술이 존재한다.
3. 관계형데이터베이스의 SQL사용 문제점
-
지루한 코드: 관계형 데이터 베이스를 사용하는 상황에서 SQL에 의존하게 된다. 이전의 포스팅에서도 MyBatis를 사용하면서 쿼리문으로 고생한 경험이 있다. -
객체지향 패러다임의 불일치: SQl을 조회할 때, 엄청 복잡해지며 테이블은 양쪽에서 서로 찾을 수 있다. (말로 표현하기 어려운 개념..) -
SQL탐색 범위 한정: 처음 실행하는 SQL에 따라 탐샘 범위가 정해진다. JPA를 사용하면서 객체그래프 탐색가능하다. -
엔티티 신뢰 문제: 레이어드 아키텍처는 물리적으로는 괜찮지만 논리적으로는 코드를 눈으로 보지않는이상 알수 없다. -
계층형 아키텍처: 진정한 의미의 계층 분할이 쉽지않다.
4. 영속성 컨텍스트 (Persistence Context)
엔티티를 영구 저장하는 환경이다. 영속성 컨텍스트는 눈에 보이지 않는 논리적인 개념이다.
4-1 Entity Manager Factory & Entity Manager
엔티티 매니저를 통해서 영속성 컨텍스트에 접근한다.
EntityManager.persist(entity)로 영속상태로 만들어준다.
4-2 상태
비영속(new/transient) : 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
영속(managed) : 영속성 컨텍스트에 관리되는 상태 (EntityManager를 통해 persist하는 것이다.)
준영속(detached) : 영속성 컨텍스트에 저장되었다가 분리된 상태 (영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.)
삭제 : 삭제된 상태
4-3 1차 캐시
한 트랜잭션안에서 데이터베이스에서 찾는 것이 아니라, 먼저 캐시에서 요청한다.
4-4 변경 감지
자바컬렉션에과 같이 JPA는 변경을 해주면 다른 코드없이 변경을 감지해서 저장해준다.
엔티티와 스냅샷(최초로 영속성 컨텍스트를 읽은 시점)을 전부 비교하고 업데이트 쿼리를 데이터베이스에 반영한다.
4-5 flush
영속성 컨텍스트의 변경내용을 데이터베이스에 반영
쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다. 하지만 1차캐시는 지워지지 않는다.
em.flush() , 트랜잭션 커밋, JPQL쿼리 실행 시 플러시 자동호출
4-6 detach
특정 객체만 준영속성으로 만들면
em.detach(특정객체),em.clear()는 전체 영속성 컨텍스트와 1차캐시를 지워준다.em.close()는 영속성 컨텍스트를 완전히 종료한다.
참고
