<div id="readability-page-1" class="page"><div><h2 id="jpa">JPA</h2>
<ul>
<li>SQL 중심에서 벗어나기 위해 만들어 짐.</li>
<li>자바 진영의 ORM 기술 표준이다.</li>
<li>인터페이스의 모음이다.</li>
<li>하이버네이트는 JPA의 구현체이다.</li>
<li>collection(ex. list)를 쓰듯이 사용하기 위함이다.(Repository를 하나의 컬렉션으로 생각가능)</li>
</ul>
<h3 id="영속성-컨텍스트엔티티-매니저">영속성 컨텍스트(엔티티 매니저)</h3>
<ul>
<li>하나의 트랜잭션 당 하나가 생성</li>
<li>한 번의 요청에 대해 캐싱이 동작.(서로 다른 요청에 대해서는 캐싱된 정보를 사용할 수 없다. 트랜잭션이 다르기 때문에 서로 다른 엔티티 매니저를 사용하기 때문)</li>
<li>트랜잭션 커밋 되는 순간 영속성 컨텍스트(내부의 쓰기 지연 sql 저장소 - 물리적 개념이 아닌 <strong>논리적 개념!</strong>)에 담겨있는 정보를 DB에 flush 한다.</li>
<li>변경 감지(더티 체크)<ul>
<li>1차 캐시에는 스냅샷이라는 게 존재한다. 처음에 영속화 된 상태를 기록해두고, 엔티티와 스냅샷을 비교해서 값이 달라진 경우 update 쿼리를 생성하고, flush &amp; commit한다.(변경되었다가 다시 원래 상태로 돌아가있다면, update 쿼리를 생성하지 않는다. )</li>
</ul></li>
<li>기본적으로 서비스 코드에 트랜잭션이 있어야한다.(단 건 쿼리는 DB 내부적으로 트랜잭션을 처리하는 로직이 존재한다(?))</li>
<li>Persistence 클래스에서 persistence.xml 설정 정보를 읽어서 EntityManagerFactory 를 만들고, 필요할 때마다 EntityManager를 생성해서 사용.</li>
<li>EntityManagerFactory는 어플리케이션 전체에서 하나만 만들어 공유해서 사용한다.(싱글톤)</li>
<li>EntityManager는 스레드 간에 공유하면 안되기 때문에, 쓰고 버린다.</li>
</ul>
<h3 id="엔티티-생명주기">엔티티 생명주기</h3>
<ul>
<li>비영속(new/transient) : 방금 생성한 경우. 메모리 상에서는 관리 중이지만, 영속성 컨텍스트나 DB 상에서는 관리를 안 하는 상태. 영속성 컨텍스트와 전혀 상관 없는 상태.</li>
<li>영속(managed) : save, findById, findByName 과 같은 메서드를 호출하여 실제로 영속성 컨텍스트에 의해 관리되고 있는 상태. DB에는 실제로 존재하는지 안 하는지 모름.</li>
<li>준영속(detached) : 영속성 컨텍스트가 관리중이다가, 강제로 관리하지 말라고 분리된 상태. 강제로 분리시키거나, 트랜잭션 범위를 벗어난 경우.</li>
<li>삭제(removed) : 영속성 컨텍스트에서 삭제된 상태.</li>
</ul>
<h3 id="연관-관계-매핑">연관 관계 매핑</h3>
<ul>
<li>연관된 모든 엔티티는 영속 상태여야한다.</li>
</ul>
<p>MappedBy : 누가 fk를 가지고 있나.(mappedBy 옵션을 주지 않으면 mapper 테이블이 생성되고, mappedBy 옵션을 주면 alter 테이블로 처리된다.)</p>
<p>연관 관계의 주인 == 외래키 관리자 == fk를 가지고 있는 녀석.</p>
<p>(추가하기)</p>
<h3 id="jpa-사용-이유">JPA 사용 이유</h3>
<ul>
<li>생산성 : 이미 다 만들어져 있다. 메서드 호출만 하면 된다.<ul>
<li>저장 : jpa.persist(member)</li>
<li>조회 : Member member =  jpa.find(memberId);</li>
<li>수정 : member.setName(“변경 이름”);</li>
<li>삭제 : jpa.remove(member);</li>
</ul></li>
<li>유지 보수<ul>
<li>필드가 추가되더라도, 객체에만 추가해주면된다. sql은 jpa가 알아서 해줌</li>
<li>h2를 쓰던, Mysql을 쓰던 dialect 설정만 변경해주면, 알아서 처리해준다.</li>
</ul></li>
<li>패러다임 불일치 해결</li>
<li>성능 최적화<ul>
<li>1차 캐시와 동일성 보장<ul>
<li>같은 트랜잭션 안에서는 같은 엔티티 반환</li>
</ul></li>
<li>트랜잭션을 지원하는 쓰기 지연</li>
<li>지연 로딩과 즉시 로딩<ul>
<li>지연 로딩 : 객체가 실제 사용될 때 로딩</li>
<li>즉시 로딩 : Join sql로 한번에 연관된 객체까지 미리 조회</li>
</ul></li>
</ul></li>
</ul>
<h3 id="orm">ORM</h3>
<ul>
<li>객체는 객체대로 설계</li>
<li>관계형 테이블은 관계형 테이블대로 설계</li>
<li>객체와 관계형 테이블의 차이는 ORM이 중간에서 매핑</li>
</ul>
<h3 id="객체와-관계형-db의-차이">객체와 관계형 DB의 차이</h3>
<ol>
<li>상속</li>
<li>연관 관계</li>
<li>데이터 타입</li>
<li>데이터 식별 방법</li>
</ol>
<h3 id="저장--조회-동작">저장 &amp; 조회 동작</h3>
<ul>
<li>[저장]<ul>
<li>Entity 분석</li>
<li>Insert Sql 생성</li>
<li>JDBC API 사용 -&gt; DB와 연결</li>
<li><strong>패러다임 불일치 해결</strong></li>
</ul></li>
<li>[조회]<ul>
<li>Select sql 생성</li>
<li>Jdbc api 사용</li>
<li>ResultSet 매핑</li>
<li><strong>패러다임 불일치 해결</strong></li>
</ul></li>
</ul>
<h3 id="jpql">JPQL</h3>
<p>SQL을 추상화한 객체 지향 쿼리.(특정 DB에 의존적이지 않다) 테이블을 기준으로 쿼리를 날리는 것이 아닌 엔티티 객체를 기준으로 쿼리를 날림</p>
<pre><code>ex<span>.</span> <span>select</span> m <span>from</span> Member <span>as</span> m</code></pre>
<h3 id="동일성-보장">동일성 보장</h3>
<p>영속성 컨텍스트가 메모리 상에 캐싱하기 때문. 조회 시 영속성 컨텍스트의 1차 캐시를 찾아보고 없으면 DB에 접근해서 찾는다. DB에 접근하게 되면, 1차 캐시에도 저장해준다.</p>
<h2 id="spring-data-jpa">Spring data JPA</h2>
<h3 id="findbyid--findbyname">findById &amp; findByName</h3>
<p>1차 캐시는 키 값을 id로 가진 객체들이 저장된다.</p>
<p>따라서 findById는 1차 캐시에서 찾아볼 수 있다. 하지만 findByName은 name을 키 값으로 가진 객체가 없기 때문에 DB에서 조회한다. findByName은 JPQL을 사용하는 것이다.</p>
<h3 id="jpql-id-generator">JPQL, ID Generator</h3>
<p>JPQL, ID Generator가 사용되면 내부적으로 flush가 일어난다.</p>
<pre><code><span>@Test</span>
<span>void</span> <span>update</span><span>(</span><span>)</span> <span>{</span>
    <span>// 트랜잭션 락</span>
    <span>Station</span> station1 <span>=</span> stationRepository<span>.</span><span>save</span><span>(</span><span>new</span> <span>Station</span><span>(</span><span>"잠실역"</span><span>)</span><span>)</span><span>;</span>
    station1<span>.</span><span>changeName</span><span>(</span><span>"몽촌토성역"</span><span>)</span><span>;</span>
    <span>// 트랜잭션 flush(JPQL, ID Generator이 동작할 때 ‘플러시(flush)’ 일어남)</span>
    <span>Station</span> station2 <span>=</span> stationRepository<span>.</span><span>findByName</span><span>(</span><span>"몽촌토성역"</span><span>)</span><span>;</span> <span>// JPQL</span>
    <span>assertThat</span><span>(</span>station2<span>)</span><span>.</span><span>isNotNull</span><span>(</span><span>)</span><span>;</span>
    <span>// 트랜잭션 커밋</span>
    <span>// 트랜잭션 언락(언락 되기 전까지는 DB반영이 아니라, 특정 공간에 로그가 쌓임. 중간에 오류 발생시 로그 다 날려서 롤백)</span>
<span>}</span></code></pre>
<p>아래 예시에는 findByName이 사용되기 전 flush가 먼저 일어난다.</p>
<h3 id="norepositorybean">@NoRepositoryBean</h3>
<p>Jpa를 사용할 때, <code>JpaRepository&lt;엔티티, ID타입&gt;</code> 를 상속해서 Repository를 만든다.</p>
<p><code>JpaRepository</code> 내부에 보면 클래스 레벨에 <code>@NoRepositoryBean</code>가 붙어져 있다. <code>JpaRepository</code> 뿐만 아니라, 그 부모 클래스인 <code>PagingAndSortingRepository</code>, <code>CrudRepository</code>에도 <code>@NoRepositoryBean</code>가 존재한다.</p>
<p><a href="https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/repository/NoRepositoryBean.html">공식 문서</a>에 보면 이렇게 나와있다.</p>
<blockquote>
<div><p>Annotation to exclude repository interfaces from being picked up and thus in consequence getting an instance being created.</p><p>
This will typically be used when providing an extended base interface for all repositories in combination with a custom repository base class to implement methods declared in that intermediate interface. In this case you typically derive your concrete repository interfaces from the intermediate one but don't want to create a Spring bean for the intermediate interface.</p></div>
</blockquote>
<p>이 어노테이션이 붙어있으면, 실제 프록시 빈으로 등록하지 않게 해주는 어노테이션이라고 한다. 그래서 중간 단계의 Repository 들을 빈으로 등록하지 않으려고 붙여져있다.</p>
<h3 id="jparepository는-인터페이스-타입인데-어떻게-동작하는가">JpaRepository는 인터페이스 타입인데 어떻게 동작하는가?</h3>
<p><code>JpaRepository</code>를 상속하면, Spring Data JPA가 인터페이스에 대해서 프록시 구현체를 만든 뒤, 구현체를 주입해준다.(의존성 주입)</p>
<h3 id="jparepository-상속시-repository를-붙여주지-않아도-되는-이유">JpaRepository 상속시 @Repository를 붙여주지 않아도 되는 이유</h3>
<p>spring data JPA는 스프링이 만들어서 제공하는 컴포넌트이므로, @Repository를 생략해도 JPA 관련 예외를 스프링 예외로 변환해서 제공해준다.</p>
<p>또 JpaRepository를 상속하면 @Repository가 없어도 빈으로 등록되는데, 이는 컴포넌트 스캔에 의해 빈으로 동작하는 것이 아니라, spring data에서 해당 인터페이스를 구현한 클래스를 찾아서 사용한다. 실제로는 인터페이스를 구현한 클래스를 바로 사용하는게 아니라, 스프링이 동적으로 임의의 구현 클래스를 생성하고, 내가 구현한 클래스를 연결해준다.</p>
<p>참고<br>
<a href="https://www.inflearn.com/questions/110045">JpaRepository나 CrudRepository 같은 인터페이스에 @Repository 어노테이션이 안붙는 이유에 대해서 궁금합니다.</a></p>
<h2 id="스프링">스프링</h2>
<h3 id="빈-생명-주기">빈 생명 주기</h3>
<p>(추가하기)</p>
<h2 id="기타">기타</h2>
<h3 id="세션의-확장성">세션의 확장성</h3>
<p>세션은 확장하기 불편하다. 서버가 늘어나면, 서버마다 세션 정보를 관리하는 저장소를 가지거나, 공통으로 세션 정보를 관리하는 저장소가 필요한데, 서버마다 관리하면 동기화에 있어 비용이 들고, 공통으로 관리해주면 별도의 저장소를 만들어야하기 때문에 비용이 든다. 따라서 세션은 확장성이 좋지 않다.</p></div></div>

air.log

JPA
SQL 중심에서 벗어나기 위해 만들어 짐.
자바 진영의 ORM 기술 표준이다.
인터페이스의 모음이다.
하이버네이트는 JPA의 구현체이다.
collection(ex. list)를 쓰듯이 사용하기 위함이다.(Repository를 하나의 컬렉션으로 생각가능)
영속성 컨텍스트(엔티티 매니저)
하나의 트랜잭션 당 하나가 생성
한 번의 요청에 대해 캐싱이 동작.(서로 다른 요청에 대해서는 캐싱된 정보를 사용할 수 없다. 트랜잭션이 다르기 때문에 서로 다른 엔티티 매니저를 사용하기 때문)
트랜잭션 커밋 되는 순간 영속성 컨텍스트(내부의 쓰기 지연 sql 저장소 - 물리적 개념이 아닌 논리적 개념!)에 담겨있는 정보를 DB에 flush 한다.
변경 감지(더티 체크)
1차 캐시에는 스냅샷이라는 게 존재한다. 처음에 영속화 된 상태를 기록해두고, 엔티티와 스냅샷을 비교해서 값이 달라진 경우 update 쿼리를 생성하고, flush & commit한다.(변경되었다가 다시 원래 상태로 돌아가있다면, update 쿼리를 생성하지 않는다. )
기본적으로 서비스 코드에 트랜잭션이 있어야한다.(단 건 쿼리는 DB 내부적으로 트랜잭션을 처리하는 로직이 존재한다(?))
Persistence 클래스에서 persistence.xml 설정 정보를 읽어서 EntityManagerFactory 를 만들고, 필요할 때마다 EntityManager를 생성해서 사용.
EntityManagerFactory는 어플리케이션 전체에서 하나만 만들어 공유해서 사용한다.(싱글톤)
EntityManager는 스레드 간에 공유하면 안되기 때문에, 쓰고 버린다.
엔티티 생명주기
비영속(new/transient) : 방금 생성한 경우. 메모리 상에서는 관리 중이지만, 영속성 컨텍스트나 DB 상에서는 관리를 안 하는 상태. 영속성 컨텍스트와 전혀 상관 없는 상태. 
영속(managed) : save, findById, findByName 과 같은 메서드를 호출하여 실제로 영속성 컨텍스트에 의해 관리되고 있는 상태. DB에는 실제로 존재하는지 안 하는지 모름.
준영속(detached) : 영속성 컨텍스트가 관리중이다가, 강제로 관리하지 말라고 분리된 상태. 강제로 분리시키거나, 트랜잭션 범위를 벗어난 경우.
삭제(removed) : 영속성 컨텍스트에서 삭제된 상태.
연관 관계 매핑
연관된 모든 엔티티는 영속 상태여야한다.
MappedBy : 누가 fk를 가지고 있나.(mappedBy 옵션을 주지 않으면 mapper 테이블이 생성되고, mappedBy 옵션을 주면 alter 테이블로 처리된다.)
연관 관계의 주인 == 외래키 관리자 == fk를 가지고 있는 녀석.
(추가하기)
JPA 사용 이유
생산성 : 이미 다 만들어져 있다. 메서드 호출만 하면 된다.
저장 : jpa.persist(member)
조회 : Member member =  jpa.find(memberId);
수정 : member.setName(“변경 이름”);
삭제 : jpa.remove(member);
유지 보수
필드가 추가되더라도, 객체에만 추가해주면된다. sql은 jpa가 알아서 해줌
h2를 쓰던, Mysql을 쓰던 dialect 설정만 변경해주면, 알아서 처리해준다.
패러다임 불일치 해결
성능 최적화 
1차 캐시와 동일성 보장
같은 트랜잭션 안에서는 같은 엔티티 반환 
트랜잭션을 지원하는 쓰기 지연
지연 로딩과 즉시 로딩
지연 로딩 : 객체가 실제 사용될 때 로딩
즉시 로딩 : Join sql로 한번에 연관된 객체까지 미리 조회
ORM
객체는 객체대로 설계
관계형 테이블은 관계형 테이블대로 설계
객체와 관계형 테이블의 차이는 ORM이 중간에서 매핑
객체와 관계형 DB의 차이
상속
연관 관계
데이터 타입
데이터 식별 방법
저장 & 조회 동작
[저장]
Entity 분석
Insert Sql 생성
JDBC API 사용 -> DB와 연결
패러다임 불일치 해결
[조회]
Select sql 생성
Jdbc api 사용
ResultSet 매핑
패러다임 불일치 해결
JPQL
SQL을 추상화한 객체 지향 쿼리.(특정 DB에 의존적이지 않다) 테이블을 기준으로 쿼리를 날리는 것이 아닌 엔티티 객체를 기준으로 쿼리를 날림
ex. select m from Member as m
동일성 보장
영속성 컨텍스트가 메모리 상에 캐싱하기 때문. 조회 시 영속성 컨텍스트의 1차 캐시를 찾아보고 없으면 DB에 접근해서 찾는다. DB에 접근하게 되면, 1차 캐시에도 저장해준다.
Spring data JPA
findById & findByName
1차 캐시는 키 값을 id로 가진 객체들이 저장된다.
따라서 findById는 1차 캐시에서 찾아볼 수 있다. 하지만 findByName은 name을 키 값으로 가진 객체가 없기 때문에 DB에서 조회한다. findByName은 JPQL을 사용하는 것이다.
JPQL, ID Generator
JPQL, ID Generator가 사용되면 내부적으로 flush가 일어난다.
@Test
void update() {
    // 트랜잭션 락
    Station station1 = stationRepository.save(new Station("잠실역"));
    station1.changeName("몽촌토성역");
    // 트랜잭션 flush(JPQL, ID Generator이 동작할 때 ‘플러시(flush)’ 일어남)
    Station station2 = stationRepository.findByName("몽촌토성역"); // JPQL
    assertThat(station2).isNotNull();
    // 트랜잭션 커밋
    // 트랜잭션 언락(언락 되기 전까지는 DB반영이 아니라, 특정 공간에 로그가 쌓임. 중간에 오류 발생시 로그 다 날려서 롤백)
}
아래 예시에는 findByName이 사용되기 전 flush가 먼저 일어난다.
@NoRepositoryBean
Jpa를 사용할 때, JpaRepository<엔티티, ID타입> 를 상속해서 Repository를 만든다.
JpaRepository 내부에 보면 클래스 레벨에 @NoRepositoryBean가 붙어져 있다. JpaRepository 뿐만 아니라, 그 부모 클래스인 PagingAndSortingRepository, CrudRepository에도 @NoRepositoryBean가 존재한다.
공식 문서에 보면 이렇게 나와있다.
Annotation to exclude repository interfaces from being picked up and thus in consequence getting an instance being created.
이 어노테이션이 붙어있으면, 실제 프록시 빈으로 등록하지 않게 해주는 어노테이션이라고 한다. 그래서 중간 단계의 Repository 들을 빈으로 등록하지 않으려고 붙여져있다.
JpaRepository는 인터페이스 타입인데 어떻게 동작하는가?
JpaRepository를 상속하면, Spring Data JPA가 인터페이스에 대해서 프록시 구현체를 만든 뒤, 구현체를 주입해준다.(의존성 주입)
JpaRepository 상속시 @Repository를 붙여주지 않아도 되는 이유
spring data JPA는 스프링이 만들어서 제공하는 컴포넌트이므로, @Repository를 생략해도 JPA 관련 예외를 스프링 예외로 변환해서 제공해준다.
또 JpaRepository를 상속하면 @Repository가 없어도 빈으로 등록되는데, 이는 컴포넌트 스캔에 의해 빈으로 동작하는 것이 아니라, spring data에서 해당 인터페이스를 구현한 클래스를 찾아서 사용한다. 실제로는 인터페이스를 구현한 클래스를 바로 사용하는게 아니라, 스프링이 동적으로 임의의 구현 클래스를 생성하고, 내가 구현한 클래스를 연결해준다.
참고
 JpaRepository나 CrudRepository 같은 인터페이스에 @Repository 어노테이션이 안붙는 이유에 대해서 궁금합니다.
스프링
빈 생명 주기
(추가하기)
기타
세션의 확장성
세션은 확장하기 불편하다. 서버가 늘어나면, 서버마다 세션 정보를 관리하는 저장소를 가지거나, 공통으로 세션 정보를 관리하는 저장소가 필요한데, 서버마다 관리하면 동기화에 있어 비용이 들고, 공통으로 관리해주면 별도의 저장소를 만들어야하기 때문에 비용이 든다. 따라서 세션은 확장성이 좋지 않다.

[새배내] level3 프로젝트 하면서 배운 내용

댓글