영원히 남는 기록, 재밌게 쓰자

프록시를 왜 사용해야할까? 예제를 통해 알아보자 멤버 하나를 조회할 때 팀의 정보도 데이터 베이스로 부터 한번에 조회를 해야할까? 그럴 경우가 있을 수 있다. 또는 반대로 멤버를 조회할 때에 멤버만 조회하고 싶은 경우가 있다. 프록시 초기화는 처음에는 아무것도 없는 빈 껍데기 프록시 객체만 가지고 있다. 타겟이라는 변수를 초기화 시킬 때 영속성 컨텍스트에 진짜 엔티티 객체를 요청하는 동작을 거친다. 꼭 필요한 데이터를 적절한 때에 가져오기 위해서 하이버네이트에서는 프록시 객체를 사용하는 기능을 제공한다. em.find()와 em.getReference() (em: 엔티티 매니저) em.find() → 실제 엔티티 조회 em.getReference() → 프록시 가자 객체를 조회 (DB를 거치지 않아 빈껍..

모든 연관 관계에는 단방향과 양방향이 존재한다. 연관 관계 매핑의 종류에는 다대일 일대다 일대일 다대다 크게 4가지 종류로 분류된다. 연관 관계에서는 중요한 것은 시나리오 룰을 정하는 것이 중요하다. 단방향 매핑 예제의 룰은 회원과 팀이 있고 회원은 하나의 팀을 가질 수 있고 팀은 여러 회원을 가질 수 있다고 가정했다. 💡 예제에서는 다대일 관계일 때 단방향과 양방향 관계를 어떻게 설정하는지 다루려고 한다. 테이블의 입장으로 보았을 때는 회원과 팀은 다대일 관계를 가진다. 객체 입장에서는 테이블과 연관 관계 페러다임을 일치시켜주는 것이 좋다. 그 입장으로 보았을 때 객체를 테이블에 맞추어 모델링을 하는 경우를 생각해보면 위와 같이 Member에는 teamId 필드를 추가할 수 있다. 이렇게 되면 memb..

플러시가 발생한다고 해서 트랜잭션이 커밋되는 것은 아니다. 플러시로 보낸 다음 tx.commit()과 같이 트랜잭션 커밋을 따로 해줘야 한다. flush()를 직접 호출할 일은 잘 없긴하다. flush()를 하는 경우를 보면 em.flush()와 같이 직접 플러시를 호출 트랜잭션의 commit 호출 시 자동 플러시 호출 JPQL 쿼리 실행 시 플러시가 자동 호출 플러시가 발생한다고 1차 캐시가 비워지는가? 아니다 플러시가 발생한 경우 변경 감지를 하여 변경이 되었거나 조회, 삭제 등으로 쓰기 지연 SQL 저장소에 쌓여있던 SQL 들이 실행되어 데이터 베이스에 반영이 되는 과정이다. 그래서 1차 캐시를 비우지 않는다. 플러시는 영속성 컨텍스트를 비우는 작업이 아니다. 영속성 컨텍스트의 변경 내용을 데이터 ..

영속성 컨텍스트는 애플리케이션과 데이터 베이스 사이에서 데이터를 관리하는 징검다리 역할을 한다. 즉, 객체와 관계형 데이터 베이스를 매핑 해주는 역할을 한다. 이런 역할을 수행하는 것이 영속성 컨텍스트이다 위 두 가지는 JPA에서 가장 중요한 2가지이다. 영속성 컨텍스트를 알아 보기 전에 JPA의 기본적인 동작 방식을 알아야 한다. 엔티티 매니저 팩토리와 엔티티 매니저의 관계를 먼저 알 필요가 있다. EntityManagerFactory는 애플리케이션이 띄워지는 시점에서 DB당 딱 하나만 생성이 된다. EntityManager는 고객의 요청이 올 때마다 생성되고 요청이 마무리 될 때 트랜잭션이 종료될 때 함께 종료된다는 것을 기억하자. 또한 EntityManager는 스레드 간 절대 공유하면 안된다.. ..