@Transactional 주석 업무 가 스크롤 백 되 지 않 으 면 작 동 하지 않 는 문 제 를 해결 합 니 다.

요 며칠 동안 프로젝트 에서 내 가@Transactional 주 해 를 사용 한 것 을 발견 한 후에 이상 을 버 리 고 스크롤 백 을 하지 않 았 다.나중에 마침내 원인 을 찾 았 다.
만약 당신 도 이런 상황 이 발생 한다 면 아래 부터 조사 할 수 있 습 니 다.
특성
먼저@Transactional 주해 업무 의 특성 을 알 아 보 세 요.문 제 를 더 잘 조사 할 수 있 습 니 다.
1.service 류 태그(일반적으로 인터페이스 에 권장 하지 않 음)에@Transactional 을 추가 하면 전체 종 류 를 spring 사무 관리 에 포함 시 킬 수 있 습 니 다.모든 업무 방법 이 실 행 될 때 하나의 사 무 를 시작 하지만 이런 사 무 는 같은 관리 방식 을 사용 합 니 다.
2.@Transactional 주 해 는 Public 가 볼 수 있 는 방법 에 만 적 용 됩 니 다.proctected,private 또는 package 의 가시도 방법 에 적용 하면 잘못 보고 하지 않 지만 트 랜 잭 션 설정 은 작 동 하지 않 습 니 다.
3.기본적으로 Spring 은 unchecked 이상 에 대해 트 랜 잭 션 스크롤 백 을 진행 합 니 다.checked 이상 이면 스크롤 백 하지 않 습 니 다.
매 워?checked 이상 이 뭐야?unchecked 이상 이 뭐야?
자바 에 서 는 Error 나 Runtime Exception(예 를 들 어 빈 포인터,1/0)에 파 견 된 이상 을 unchecked 이상 이 라 고 부 르 며,기타 계승 은 자바.lang.Exception 에서 이상 한 것 을 Checked Exception 이 라 고 부 릅 니 다.예 를 들 어 IOException,TimeoutException 등 입 니 다.
좀 더 통속 적 으로:
코드 에 나타 난 빈 포인터 등 이상 을 쓰 면 스크롤 백 되 고 파일 읽 기와 쓰기,네트워크 에 문제 가 생기 면 spring 은 스크롤 백 할 수 없습니다.그리고 저 는 여러분 에 게 이것 을 어떻게 기억 하 는 지 가르쳐 드 리 겠 습 니 다.많은 친구 들 이 헷 갈 리 기 쉽 기 때 문 입 니 다.코드 를 쓸 때 일부 IOException 은 우리 의 컴 파일 러 가 감지 할 수 있 습 니 다.checked 이상 이 라 고 합 니 다.코드 를 쓸 때 빈 지침 등 이 죽어도 감지 되 지 않 기 때문에 unchecked 이상 이 라 고 합 니 다.이렇게 하면 좀 기억 하기 쉽 지 않 아 요?
4.업무 만 읽 기:

@Transactional(propagation=Propagation.NOT_SUPPORTED,readOnly=true)

읽 기 플래그 는 트 랜 잭 션 이 시 작 될 때 만 적 용 됩 니 다.그렇지 않 으 면 설정 이 무 시 됩 니 다.
시작 사 무 는 스 레 드 비용 을 증가 시 킵 니 다.데이터 베 이 스 는 공유 읽 기 때문에 잠 겨 있 습 니 다(구체 적 으로 데이터 베이스 유형 과 트 랜 잭 션 격 리 단계 와 관련 이 있 습 니 다).일반적으로 데 이 터 를 읽 을 때 만 읽 기 전용 사 무 를 설정 하지 않 고 추가 적 인 시스템 비용 을 늘 릴 필요 가 없다.
2.트 랜 잭 션 전파 모드
Propagation 은 여러 가지 사무 전파 모델 을 매 거 했 고 부분 은 다음 과 같다.
1.REQUIRED(기본 모드):업무 방법 은 한 용기 에서 실행 해 야 합 니 다.만약 방법 이 실 행 될 때 이미 하나의 업무 에 처 해 있다 면,이 업무 에 가입 하 십시오.그렇지 않 으 면 자신 이 새로운 업 무 를 새로 만 듭 니 다.
2、NOT_SUPPORTED:성명 방법 은 사무 가 필요 없습니다.만약 방법 이 하나의 업무 와 관련 이 없다 면 용 기 는 그 에 게 업 무 를 열 어 주지 않 을 것 입 니 다.만약 방법 이 한 업무 에서 호출 된다 면 이 업 무 는 걸 리 고 호출 이 끝 난 후에 원래 의 업 무 는 다시 실 행 될 것 입 니 다.
3.REQUIRESNEW:사무 가 있 든 없 든 이 방법 은 항상 자신 을 위해 새로운 사 무 를 시작 합 니 다.방법 이 한 트 랜 잭 션 에서 실행 되 었 다 면 기 존 트 랜 잭 션 이 끊 기 고 새로운 트 랜 잭 션 이 생 성 됩 니 다.
4.MANDATORY:이 방법 은 이미 존재 하 는 업무 에서 만 실 행 될 수 있 고 업무 방법 은 자신의 업 무 를 시작 할 수 없습니다.만약 사무 가 없 는 환경 에서 호출 된다 면,용 기 는 예 외 를 던 져 버 릴 것 이다.
5.SUPPORTS:이 방법 이 특정한 업무 범위 에서 호출 되면 방법 은 이 업무 의 일부분 이 됩 니 다.만약 방법 이 이 사무 범위 밖에서 호출 된다 면,이 방법 은 사무 가 없 는 환경 에서 실 행 될 것 이다.
6.NEVER:이 방법 은 절대로 업무 범위 내 에서 집행 할 수 없습니다.있 으 면 예 외 를 버 려 라.이 방법 이 아무런 사무 와 관련 이 없어 야만 정상적으로 집행 할 수 있다.
7.NESTED:하나의 활동 적 인 업무 가 존재 한다 면 포 함 된 업무 에서 실 행 됩 니 다.이벤트 가 없 으 면 REQUIRED 속성 에 따라 실 행 됩 니 다.그것 은 하나의 단독 사 무 를 사 용 했 습 니 다.이 사 무 는 스크롤 백 할 수 있 는 여러 개의 저장 점 을 가지 고 있 습 니 다.내부 트 랜 잭 션 의 스크롤 백 은 외부 트 랜 잭 션 에 영향 을 주지 않 습 니 다.DataSourceTransactionManager 트 랜 잭 션 관리자 에 만 효과 가 있 습 니 다.
3.Transactional 주해 해결 스크롤 백 하지 않 음
1.당신 의 방법 이 Public 인지 확인 합 니 다.
2.당신 의 이상 유형 은 unchecked 이상 입 니까?
만약 내 가 check 이상 을 하고 싶다 면 스크롤 백 을 하고 싶다 면 어떻게 해 야 합 니까?

@Transactional(rollbackFor=Exception.class) 

비슷 한 것 은 norollbackFor 도 있 습 니 다.스크롤 백 하지 않 는 이상 을 사용자 정의 합 니 다.
3.데이터베이스 엔진 은 사 무 를 지원 해 야 합 니 다.MySQL 이 라면,주의 표 는 사 무 를 지원 하 는 엔진 을 사용 해 야 합 니 다.예 를 들 어 innodb,my isam 이 라면 사 무 는 소 용이 없습니다.
4.주석 에 대한 해석 이 열 렸 는 지 여부

<tx:annotation-driven transaction-manager="transactionManager" proxy-target-class="true"/>

5.spring 에서 이 가방 을 스 캔 할 지 여 부 는 org.test 아래 에 있 는 가방 을 스 캔 하 는 것 입 니 다.

<context:component-scan base-package="org.test" ></context:component-scan>

6.같은 종류의 방법 이 호출 되 었 는 지 확인 합 니 다(예 를 들 어 a 방법 은 같은 종류의 b 방법 을 호출 합 니 다)
7.이상 하 게 캐 치 에 걸 렸 나
이상,나중에 추가 합 시다~
추가:@Transactional 사무 몇 가지 주의
이 안 에는 여러분 이 주의해 야 할 몇 가지 가 있 습 니 다.
A.하나의 기능 이 사 무 를 수행 할 지 여 부 는 반드시 디자인,코드 에 포함 시 켜 야 합 니 다.기본 기능 만 완성 했다 고 OK 가 될 수 는 없다.
B.사 무 를 추가 하면 개발 환경 테스트(테스트 환경 도 가능 한 한 이상 을 발생 시 키 고 테스트 스크롤 백)를 잘 하여 업무 의 효력 을 확보 해 야 한다.
C.아래 의 사무 사용 과정의 주의사항 을 유의 하 시기 바 랍 니 다.
1.인터페이스 에@Transactional 을 설명 하지 말고 구체 적 인 방법 에@Transactional 주 해 를 사용 해 야 합 니 다.그렇지 않 으 면 주석 이 올 바 르 지 않 을 수 있 습 니 다.
2.편리 하 게 하려 고 하지 마 세 요.@Transactional 을 클래스 급 성명 에 두 고 클래스 성명 에 두 면 모든 방법 에 사무 가 있 습 니 다.그러므로@Transactional 은 방법 단계 에 두 어야 합 니 다.사 무 를 사용 하지 않 아 도 됩 니 다.예 를 들 어 조회 방법 과 같은 사 무 를 두 지 마 십시오.그렇지 않 으 면 성능 에 영향 을 미친다.
3.@Transactional 방법 을 사 용 했 습 니 다.같은 종류의 방법 을 호출 했 습 니 다.@Transactional 은 잘못 되 었 습 니 다.예 를 들 어 하나의 Test 가 있 습 니 다.그것 의 한 방법 A,A 는 Test 와 같은 방법 B(B 가 Public 이 든 private 든)를 다시 호출 합 니 다.그러나 A 는 주 해 를 밝 히 지 않 았 고 B 는 있 습 니 다.외부 에서 A 를 호출 하면 B 의 사 무 는 작용 하지 않 습 니 다.(자주 이곳 에서 오류 가 발생 한다)
4.@Transactional 방법 을 사 용 했 습 니 다.Public 만 사용 할 수 있 습 니 다.@Transactional 주 해 는 외부 다른 클래스 에 의 해 호출 되 어야 유효 하기 때문에 Public 만 사용 할 수 있 습 니 다.이 치 는 위의 것 과 관련 이 있다.따라서 proctected,private 또는 package-visible 방법 에@Transactional 주 해 를 사용 하면 잘못 보고 하지 않 지만 사 무 는 잘못 되 었 습 니 다.
5.ICORE-CLAIM 에서 테스트 한 결과 효 과 는 다음 과 같다.
A.조사 이상 XXX Exception 을 던 지면 업무 가 다시 굴 러 갑 니 다.
B.실행 중 이상 NullPointer Exception 을 던 지면 트 랜 잭 션 이 다시 굴 러 갑 니 다.
C.Quartz 에서 execute 는@Transactional 방법 을 직접 호출 하여 스크롤 백 할 수 있 습 니 다.간접 호출,스크롤 백 하지 않 습 니 다.위 에서 3 시 에 언급 한 것)
D.비동기 작업 에서 execute 는@Transactional 방법 을 직접 호출 하여 스크롤 백 할 수 있 습 니 다.간접 호출,스크롤 백 하지 않 습 니 다.위 에서 3 시 에 언급 한 것)
E.action 에@Transactional 을 더 하면 스크롤 백 하지 않 습 니 다.action 에 사 무 를 더 하지 말 라 는 것 을 명심 하 세 요.
F.service 에@Transactional 을 더 하면 action 이 이 방법 을 직접 바 꾸 면 스크롤 백 을 하고 간접 적 으로 바 꾸 면 스크롤 백 을 하지 않 습 니 다.(위 에서 언급 한 것)
G.서비스 에 있 는 private 에@Transactional 을 더 하면 트 랜 잭 션 이 스크롤 백 되 지 않 습 니 다.
이상 은 개인 적 인 경험 이 므 로 여러분 에 게 참고 가 되 기 를 바 랍 니 다.여러분 들 도 저 희 를 많이 응원 해 주시 기 바 랍 니 다.만약 잘못 이 있 거나 완전히 고려 하지 않 은 부분 이 있다 면 아낌없이 가르침 을 주시 기 바 랍 니 다.