Hibernate 세 션 트 랜 잭 션 격 리 단계 지구 화 대상 의 상 태 를 되 돌아 보 는 세 션 핵심 방법

1. Session 개술 Session 인 터 페 이 스 는 Hibernate 가 응용 프로그램 에 제공 하 는 데이터 베 이 스 를 조작 하 는 가장 주요 한 인터페이스 로 기본 적 인 저장, 업데이트, 삭제, 자바 대상 을 불 러 오 는 방법 을 제공 합 니 다.모든 Session 대상 은 메모리 에 캐 시 를 유지 하고 있 습 니 다. 캐 시 에 있 는 대상 을 지구 화 대상 이 라 고 부 르 며 데이터베이스 시트 의 관련 기록 과 대응 하 는 관 계 를 유지 하고 있 습 니 다.세 션 캐 시 를 통 해 Hibernate 는 응용 프로그램 이 데이터베이스 에 접근 하 는 횟수 를 최대한 줄 이 고 메모리 공간 을 더욱 효과적으로 활용 할 수 있 도록 했다.Hibernate 는 지구 화 클래스 의 대상 을 지구 화 상태, 임시 상태, 유리 상태, 삭제 상태 등 4 가지 상태 로 나눈다.Session 의 특정 방법 은 대상 을 한 상태 에서 다른 상태 로 전환 시 킬 수 있다.2. Session 캐 시 는 응용 시스템 개발 과정 에서 캐 시 를 사용 하 는 것 이 프로그램의 성능 을 향상 시 키 는 주요 한 수단 이다.Hibernate 에서 Session 대상 은 스 레 드 급 의 1 급 캐 시 를 유지 하고 Session Factory 는 프로 세 스 급 의 2 급 캐 시 를 유지 합 니 다.2 급 캐 시 는 다음 장 에서 자세히 소개 합 니 다. 지금 은 Session 이 유지 하 는 1 급 캐 시 에 관심 을 가 집 니 다.
2.1 세 션 캐 시 를 사용 하 는 장점 ① 데이터 베 이 스 를 방문 하 는 횟수 를 줄 이 고 session. get (Student. class, 1) 을 두 번 호출 합 니 다.방법, SQL 문 구 를 1 개 만 보 냅 니 다.처음 get () 방법 으로 불 러 온 Student 는 메모리 에 캐 시 되 었 고, 두 번 째 호출 get () 방법 은 메모리 에 캐 시 된 Student 대상 을 직접 사용 하여 데이터 베 이 스 를 방문 하 는 횟수 를 줄 였 기 때 문 입 니 다.Tips: 응용 프로그램 에서 데이터 베 이 스 를 방문 하 는 횟수 는 흔히 가장 주요 한 성능 병목 입 니 다.② 메모리 에 있 는 데이터 의 변 화 를 데이터베이스 에 자동 으로 동기 화하 여 session. get (Student. class, 1) 을 사용 합 니 다.방법 은 Student 대상 을 메모리 에 불 러 오 면 Student 대상 은 Session 대상 관리 에 있 습 니 다.이 때 student. setStuName ("a") 을 호출 합 니 다.방법 은 데이터베이스 테이블 에 대응 하 는 데이터 기록 에 대한 Hibernate 의 수정 을 촉발 합 니 다. 즉, UPDATE 문장 을 보 내 서 Student 대상 이 데이터베이스 테이블 에 대응 하 는 기록 을 업데이트 합 니 다.하 이 버 네 이 트 의 가장 큰 특징 은 데이터베이스 기록 에 대한 조작 을 자바 대상 에 대한 조작 으로 전환 해 개발 을 간소화 하 는 것 이다.
2.2 Session 캐 시 작업 개요 ① flush: 푸 시.캐 시 에 있 는 데이터 의 변 화 를 데이터베이스 에 구현 ② refresh: 새로 고침.데이터베이스 의 데이터 변 화 를 캐 시 에 추출 ③ clear: 비 웁 니 다.세 션 캐 시 비우 기
2.3 flush 작업 ① Session 대상 은 기본적으로 어떤 상황 에서 flush 작업 을 수행 합 니까?② 기본 적 인 상황 에서 Session 이 flush 작업 을 수행 할 시기: [1] 세 션 의 flush () 방법 [2] 을 명시 적 으로 호출 할 때 Transaction 대상 의 commt () 방법 을 호출 할 때 flush 캐 시 를 먼저 하고 사 무 를 제출 하기 전에 HQL, QBC 조 회 를 실행 하기 전에 flush 캐 시 를 사용 하여 HQL 또는 QBC 에서 조회 한 데이터 가 최신 임 을 보증 합 니 다.③ 관련 문제 [1] 지구 화 대상 의 속성 값 을 수정 하여 SQL 문 구 를 즉시 보 내지 않 고 업 무 를 제출 하기 전에 flush 작업 을 수행 할 때 해당 하 는 UPDATE 문 구 를 보 냅 니 다.[2] UPDATE 문 구 를 보 낼 때 데이터 의 수정 이 즉시 적용 되 지 않 으 며, 업 무 를 제출 한 후에 야 데이터 의 수정 이 영구적 으로 저 장 됩 니 다.
2.4 refresh 작업 과 트 랜 잭 션 격 리 단계 ① 문 제 를 제기 합 니 다. MySQL 클 라 이언 트 를 사용 하여 데 이 터 를 수정 한 후에 refresh () 방법 으로 읽 은 것 입 니까? 아니면 오래된 수정 되 지 않 은 데 이 터 를 읽 은 것 입 니까? 왜 요?② MySQL 의 기본 데이터베이스 트 랜 잭 션 격 리 단 계 를 분석 하 는 것 은 '중복 읽 기 가능' 입 니 다. 현재 트 랜 잭 션 수행 기간 에 서로 다른 시간 에 읽 은 데 이 터 를 똑 같이 보장 해 야 합 니 다.③ 결론 refresh () 방법 으로 읽 은 데이터 가 실제 최신 데이터 인지 아 닌 지 는 현재 트 랜 잭 션 격 리 단 계 를 참조 해 야 한다.
3. 트 랜 잭 션 격 리 단 계 는 3.1 데이터베이스 트 랜 잭 션 병행 문 제 를 돌 이 켜 보면 현재 두 가지 업무 가 있다 고 가정 합 니 다. Transaction 01 과 Transaction 02 가 동시에 실 행 됩 니 다.① 장 독 [1] Transaction 01 은 어떤 기록 의 AGE 값 을 20 에서 30 으로 수정한다.[2] Transaction 02 는 Transaction 01 업데이트 후의 값: 30 을 읽 었 습 니 다.[3] Transaction 01 스크롤 백, AGE 값 이 20 으로 회 복 됩 니 다.[4] Transaction 02 에서 읽 은 30 은 잘못된 값 입 니 다.② 중복 읽 기 불가 [1] Transaction 01 은 AGE 값 을 20 으로 읽 었 습 니 다.[2] Transaction 02 는 AGE 값 을 30 으로 수정 합 니 다.[3] Transaction 01 에서 AGE 값 을 다시 읽 는 것 은 30 으로 처음 읽 는 것 과 일치 하지 않 습 니 다.③ 환 독 [1] Transaction 01 은 STUDENT 표 의 일부 데 이 터 를 읽 었 다.[2] Transaction 02 는 STUDENT 표 에 새 줄 을 삽입 합 니 다.[3] Transaction 01 이 STUDENT 표를 읽 었 을 때 줄 이 더 나 왔 습 니 다.
3.2 격 리 단계 데이터 베이스 시스템 은 각 업 무 를 격 리 하고 병행 하 는 능력 을 가 져 야 한다. 그들 이 서로 영향 을 주지 않 고 각종 병행 문 제 를 피해 야 한다.하나의 사무 가 다른 사무 와 격 리 되 는 정 도 를 격 리 단계 라 고 한다.SQL 표준 에 여러 가지 사무 격 리 단 계 를 규정 하고 서로 다른 격 리 단 계 는 서로 다른 간섭 정도 에 대응 하 며 격 리 단계 가 높 을 수록 데이터 의 일치 성 이 좋 지만 동시성 이 약 하 다.
① 읽 기 미 제출: READ UNCOMMITTED 는 Transaction 01 이 제출 하지 않 은 수정 사항 을 읽 을 수 있 도록 합 니 다.② 읽 기 제출: READ COMMITTED 는 Transaction 01 에 게 Transaction 02 가 제출 한 수정 사항 만 읽 을 수 있 도록 요구 합 니 다.③ 반복 읽 기 가능: REPEATABLE READ 는 Transaction 01 이 한 필드 에서 같은 값 을 여러 번 읽 을 수 있 도록 확보 합 니 다. 즉, Transaction 01 이 실행 되 는 동안 다른 사무 가 이 필드 를 업데이트 하 는 것 을 금지 합 니 다.④ 직렬 화: SERIALIZABLE 은 Transaction 01 이 한 표 에서 같은 줄 을 여러 번 읽 을 수 있 도록 확보 하고 Transaction 01 이 실행 되 는 동안 다른 사무 가 이 표를 추가, 업데이트, 삭제 하 는 것 을 금지 합 니 다.어떠한 병발 문 제 를 피 할 수 있 지만 성능 은 매우 낮다.⑤ 각 격 리 단계 에서 병발 문 제 를 해결 하 는 능력 은 다음 표 참조

*******************           **
**READ UNCOMMITTED      **
**READ COMMITTED      **
**REPEATABLE READ      **
**SERIALIZABLE      **

⑥ 각종 데이터베이스 제품 의 트 랜 잭 션 격 리 수준 지원 정도 * * * * * * * * * * * * * * * * * * Oracle - MySQL READ UNCOMMITTED×——√ READ COMMITTED √——√ REPEATABLE READ ×——√ (묵인) SERIALIZABLE √ -- √
⑦ MySQL 에 격 리 단 계 를 설정 합 니 다 [1] MySQL 프로그램 을 시작 할 때마다 데이터베이스 연결 이 따로 있 습 니 다.데이터베이스 연결 마다 전역 변수 @ @ tx 가 있 습 니 다.isolation, 현재 트 랜 잭 션 격 리 단 계 를 표시 합 니 다.[2] 현재 격 리 단계 보기: SELECT @ @ txisolation;
[3] 현재 MySQL 연결 의 격 리 단 계 를 설정 합 니 다: SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
[4] 데이터베이스 시스템 의 전역 격 리 단 계 를 설정 합 니 다: SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
⑨ Hibernate 에서 격 리 단 계 를 설정 [1] JDBC 데이터베이스 연결 은 데이터베이스 시스템 의 기본 격 리 단 계 를 사용 합 니 다.[2] Hibernate 프로필 에서 격 리 단 계 를 명시 적 으로 설정 할 수 있 습 니 다.모든 격 리 단 계 는 하나의 정수 에 대응 합 니 다: READ UNCOMMITED 1 READ COMMITED 2 REPEATABLE READ 4 SERIALIZEABLE 8 [3] 설정 방식

<!--                    -->
<property name="hibernate.connection.isolation">2</property>

4 지구 화 대상 의 상태 4.1 네 가지 상태 ① 임시 상태 [1] OID: OID 가 없습니다.예 를 들 어 new Student (null, "Kate 2015", 18, new Date ();[2] Session 캐 시 에 있 는 지 여부: [3] 데이터베이스 에 대응 하 는 기록 이 있 는 지 여부: ② 지속 상태 가 없 음 [1] OID: OID 가 있 음.예 를 들 어: Student student = (Student) session. get (Student. class, 1);[2] Session 캐 시 에 있 는 지 여부: [3] 데이터베이스 에 해당 하 는 기록 이 있 는 지 여부: ③ 유리 상태 [1] OID: OID 가 있 습 니 다.예 를 들 어 new Student (1, "Kate 2015", 18, new Date ();[2] Session 캐 시 에 있 는 지 여부: [3] 데이터베이스 에 해당 하 는 기록 이 있 는 지 여부: ④ 삭제 상태 [1] OID: OID 가 있 습 니 다.보통 삭제 작업 을 통 해 얻 을 수 있 습 니 다.[2] Session 캐 시 에 있 는 지 여부: [3] 데이터베이스 에 있 는 지 없 는 지 여부: OID Session 캐 시 에 있 는 임시 상태 가 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지 없 는 지
4.2 네 가지 상태 간 의 전환
5 Session 핵심 방법 5.1 save () ① 임시 대상 을 지구 화 대상 으로 변환 ② OID: 임시 대상 의 'OID' 값 을 무시 하고 save () 방법 은 데이터베이스 에서 발생 하 는 새로운 OID 값 을 지구 화 대상 ③ 지구 화 상태의 대상 의 OID 값 은 수정 할 수 없 는 5.2 persist () ① 작용 과 save ()동일 ② OID 가 있 는 대상 을 저장 할 수 없 으 며 이상 을 던 집 니 다: org. hibenate. PersistentObject Exception 5.3 get () ① OID 의 값 에 따라 데이터베이스 에서 대상 을 메모리 로 즉시 불 러 옵 니 다.② get () 방법 을 호출 할 때 Session 캐 시 에 OID 가 같은 대상 이 있 으 면 get () 방법 은 캐 시 에 있 는 대상 을 SQL 문 구 를 보 내지 않 고 되 돌려 줍 니 다.5.4 load () ① 지연 검색 전략 을 사용 하여 load () 방법 을 호출 할 때 하나의 프 록 시 대상 만 되 돌려 주 고 SQL 문 구 를 보 내지 않 습 니 다.비 OID 속성 값 을 실제로 사용 할 때 만 SQL 문 구 를 보 내 조회 합 니 다.② 게 으 른 불 러 오기 초기 화 이상 [1] 클래스 이름: org. hibenate. Lazy InitializationException [2] 발생 원인: 불 러 오기 지연 프 록 시 대상 을 초기 화 할 때 Session 캐 시 에 OID 에 대응 하 는 대상 이 없어 초기 화 를 완료 할 수 없습니다.5.5 update () ① 유리 대상 또는 지구 화 대상 에 따라 데이터베이스 시트 를 업데이트 ② update () 방법 으로 유리 대상 을 업데이트 할 때 기본 적 인 상황 에서 현재 유리 대상 의 데이터 와 데이터 베이스 시트 의 데이터 에 차이 가 있 는 지 알 수 없습니다.따라서 차이 가 있 든 없 든 SQL 문 구 를 보 냅 니 다.맹목적 인 업데이트 문 구 를 피하 기 위해 hbm 설정 파일 의 class 요소 에서 select - before - update 속성 값 을 true 로 설정 할 수 있 습 니 다.보통 이 속성 을 설정 하지 않 습 니 다.③ update () 방법 으로 OID 가 존재 하지 않 는 대상 을 업데이트 하면 이상 이 발생 합 니 다. org. hibenate. StealObject State Exception ④ update () 방법 으로 유리 대상 을 업데이트 합 니 다. 그러나 이 때 Session 캐 시 에는 OID 와 같은 지구 화 대상 이 존재 합 니 다. 이상 이 발생 합 니 다: org. hibenate. NonUniqueObject Exception 5.6 saveOrUpdate ()① 두 가지 기능 을 저장 하고 업데이트 한다.임시 대상 에 전송 하여 저장 하고, 유리 대상 에 전송 하여 업 데 이 트 를 수행 합 니 다.② INSERT 문 구 를 실행 하 는 지 UPDATE 문 구 를 실행 하 는 지 판단 하 는 근거 [1] OID 의 값 에 따라 null 이면 저장 을 실행 합 니 다. 그렇지 않 으 면 업 데 이 트 를 실행 합 니 다 [2] OID 의 값 이 hbm 파일 과 같 으 면 id 요소 가 설정 한 unsaved - value 속성 은 저장 작업 을 수행 합 니 다.5.7 delete () ① 삭제 작업 ② 대상 삭제 후 OID 값 비우 기: Hibernate 프로필 에 다음 설정 추가

<property name="hibernate.use_identifier_rollback" >true </property>

5.8 doWork () ① Hibernate 환경 에서 원생 을 수행 하 는 JDBC 코드 ② 예시 코드

@Test
public void testWork() {
    session.doWork(new Work() {

        @Override
        public void execute(Connection connection) throws SQLException {

            //     Connection       JDBC  ...

        }
    });
}