(JPA) Readonly 트랜잭션은 Dirty Checking을 하지 않는다
이해를 편하게 돕기 위해 엔티티는 아래와 같은 구조를 가진다.
Spring
글 9개
이해를 편하게 돕기 위해 엔티티는 아래와 같은 구조를 가진다.
글을 정리하다 보니 너무 깊게 파고 정리한 거 같아 글이 너무 길어져서 아무도 읽지 않을 것 같아 정리부터 해보겠습니다.
엔티티 매니저 팩토리는 생성 비용이 비싸서 대부분 어플리케이션 당 하나를 생성하는 편이고, 엔티티 매니저는 생성 비용이 비싸지 않아서 어플리케이션에서 여러 번 생성된다.하지만 엔티티 매니저는 쓰레드 세이프 하지 않기 때문에, 쓰레드 당 하나를 생성해야할 것 같고 Spring MVC는 리퀘스트 당 하나의 쓰레드가 할당되기…
repository의 구현체는 프록시 객체로써 인터페이스이기 때문에 jdk dynamic 프록시 객체가 생성이 된다.또한 TransactionInterceptor라는 Advisor를 가지고 있으며
어이쿠야... 정말 백만년만에 포스팅하는 것 같다... 나태하게 살지 말기로 작심만 몇 번째 하는 건지 ㅠㅠ여튼 이번에 JPA를 통해 엔터티를 용도에 맞게 잘게 쪼개보다 보니 겪었던 이슈를 간단히 정리해봤다.
일반적인 DB 테이블 구조에 맞춰 엔티티를 만들다보면 아래와 같이 만들게 된다.
이미지 출처: <박상문의 Photo & Essay>평양 육아원의 모습
드디어 유닛 테스트? 단위 테스트? JUnit을 써봤다~그럼 시작!
Hibernate를 써보자! (feat. MySQL)