강의

1.1 문제의 배경 실제 데이터베이스로 작업을 시작하면 "성급한 최적화는 모든 악의 근원입니다."라는 문구를 즉시 기억할 것입니다. 이제야 그녀를 부정적인 방식으로 기억합니다. 데이터베이스로 작업할 때 최적화는 필수 불가결합니다. 그리고 이미 설계 단계에서 작업해야 합니다. Hibernate는 데이터베이스 작업을 매우 편리하게 만듭니다. @OneToMany적절하게 주석을 달기 만 하면 자식 개체를 쉽게 가져올 수 있습니다 @M

2.1 가져오기 옵션 Hibernate의 개발자들은 오랫동안 자식 엔터티를 로드하는 문제에 대해 알고 있었습니다. 그래서 그들이 한 첫 번째 일은 주석에 특별한 가져오기@OneToMany 매개변수를 추가하는 것이었습니다 .@ManyToMany 이 매개변수는 두 가지 값을 가질 수 있습니다. 열렬한 게으른 예: @OneToMany(fetch = FetchType.LAZY, mappedBy = "user")

LazyCollectionOption.EXTRA 알아보기 그러나 가장 흥미로운 것은 LazyCollectionOption.EXTRA 값입니다. @LazyCollection 주석 의 값으로 지정하면 Hibernate는 컬렉션의 요소 로딩을 가능한 한 오랫동안 지연합니다. 컬렉션의 요소 수를 가져오려는 경우: User user = session.load(User.class, 1);

문제에 대한 설명 위에서 말했듯이 LazyCollectionOption.EXTRA 주석에는 문제가 있습니다. 각 개체에 대해 데이터베이스에 별도의 요청을 수행합니다. 우리는 부모 객체에 대한 모든 자식 객체를 즉시 로드하기를 원한다고 Hibernate에 어떻게든 설명할 필요가 있습니다. Hibernate의 개발자들은 이 문제에 대한 해결책인 HQL의 조인 인출 연산자 를 제시했습니다 . HQL 쿼리 예: select disti

캐싱 솔루션을 작성하지 마십시오 데이터베이스 작업 속도를 높이는 또 다른 방법은 이전에 이미 요청한 개체를 캐시하는 것입니다. 중요한! 자체 캐싱 솔루션을 작성하지 마십시오. 이 작업에는 꿈도 꾸지 못한 함정이 너무 많습니다. 문제 1 - 캐시 플러시 . 개체를 캐시에서 제거하거나 캐시에서 업데이트해야 할 때 이벤트가 발생하는 경우가 있습니다. 이를 유능하게 수행하는 유일한 방법은 캐시 엔진을 통해 모든 요청을 데이터베이스로

동시성 전략 Hibernate에서 2차 캐싱을 활성화한 후에는 Hibernate에 어떤 Entity 개체를 어떻게 캐싱할지 설명해야 합니다. 이를 위해 Hibernate는 Entity 클래스에 대한 특별한 주석 - @Cache를 가지고 있습니다 . 예: @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 이 주석은 두 번째 수준 캐시를 사용하려는 각 엔터티 엔터티에 대해 작성해야 합니다

쿼리 캐시가 필요한 이유 HQL에서 직원을 가져오는 예제를 다시 작성해 보겠습니다. Employee director1 = session.createQuery("from Employee where id = 4").uniqueResult();

캐싱 설정 hibernate.cfg.xml 파일의 캐싱 설정으로 돌아가 보겠습니다.