redis 결합 spring 의 트 랜 잭 션 사용

최근 에 하나의 인 터 페 이 스 는 다른 3 개의 인 터 페 이 스 를 패키지 해 야 한다.인터페이스 간 의 데 이 터 는 서로 연결 되 고 의존 해 야 한다.만약 에 인터페이스 에 이상 이 발생 하거나 주 논리 에서 이상 이 발생 하면 이번에 발생 하 는 모든 데이터 변 화 는 스크롤 백 이 필요 하 다.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
이상 할 때 데이터 스크롤 백 이 필요 하 다 는 점 을 감안 하면 가장 먼저 생각 하 는 것 이 분명 하 다.
하지만 실제 작업 에 서 는 시계 세 장 이 사용 된다.예 를 들 어 A,B,C.

@Transactional(propagation = Propagation.REQUIRED)
public void all(){
    A();   //  A 
    B();   //  B ，B    A    
    C();   //  C , C    B  A    
}

1。데이터베이스 격 리 단계 변경(부정적인 방법)
데이터 가 A 표 에 삽입 되면 B 는 A 에 삽 입 된 새로운 데 이 터 를 사용 할 수 있 습 니 다.그러나 각 사무 간 에 독립 되 어 있 지만 큰 사무 에 포함 되 어 있 기 때문에 각 사무 간 에 일치 하기 때문에 다른 업무 의 미 제출 데 이 터 를 읽 지 못 합 니 다.만약 에 옆집 단 계 를 읽 고 제출 하지 않 은 데이터 로 설정 하면 더러 운 읽 기 를 초래 할 수 있 습 니 다.중복 읽 기와 환상 읽 기 가 불가능 합 니 다.그래서 이런 방법 은 배제 되 었 다.
2。redis 로 insert 의 데 이 터 를 저장 합 니 다.
spring 이 실행 방법 을 실행 할 때,비록 업무 수행 이 완료 되 지 않 았 지만,이때 데이터베이스 에 가서 메 인 키 를 조회 하면 데이터 가 없 지만,메 인 키 는 이미 변경 되 었 음 을 발견 할 수 있 습 니 다(예 를 들 어 원시 적 인 A 표 메 인 키 는 10 입 니 다.이때 A 의 방법 을 실행 한 후에 A 표 에 대해 insert 작업 을 하고 단점 은 B 의 방법 에서 끊 어 집 니 다.B 방법 으로 실 행 될 때 우 리 는 A 표 에 가서 기록 을 봅 니 다.spring 이 아직 commt 되 지 않 았 기 때문에 A 표 는 기록 되 지 않 았 을 것 입 니 다.그러나 A 표 의 메 인 키 는 반드시 10 보다 클 것 입 니 다.사무 가 제출 되 지 않 았 을 때 데 이 터 는 메모리 에 저장 되 어야 합 니 다.이상 이 발생 하면 데이터 스크롤 을 진행 할 때 메 인 키 는 작업 전의 메 인 키 로 변 합 니 다.
상술 한 두 가지 방법 을 총 결 한 후에 최종 정론 은 틀림없이 redis 의 방법 을 사용 한 것 이다.
그러나 spring 의 트 랜 잭 션 은 스크롤 백 을 지원 합 니 다.redis 의 데 이 터 는 스크롤 백 을 지원 하지 않 습 니 다.데이터 가 점점 많아 지면 redis 는 저 장 된 데이터 의 양 이 점점 커지 는 것 이 아 닙 니까?
redis 가 트 랜 잭 션 스크롤 백 을 할 수 없 는 상황 에 대해 서 는 논리 적 으로 스크롤 백 을 설정 해 야 합 니 다.

@Transactional
    public void executeAllVoid(){
        List A = null;
        List B = null;
        try {
            A= voidA();
            B= voidB();
            voidC();
        }catch (Exception e){
            e.printStackTrace();
            logger.error("    ：",e);
            TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
        }finally {
            if(A != null) {
                redisTemplate.opsForHash().delete(keyA, A.toArray());
            }
            if(B!= null){
                redisTemplate.opsForHash().delete(keyB, B.toArray());
            }
        }
    }

A 방법 과 B 방법 을 조작 할 때 이상 이 있 으 면 위로 던 지고 가장 바깥쪽 에 도착 하 는 방법 이 있 을 때 try catch 로 이상 을 포착 합 니 다.캡 처 가 이상 할 때 redis 가 설정 한 key 는 알 수 있 기 때문에 로 컬 session 에 저장 할 수 있 고 매개 변수 로 되 돌아 갈 수 있 습 니 다.그래서 저 희 는 catch 가 이상 할 때 수 동 redis 삭제 작업 을 통 해 redis 의 가짜 스크롤 백 상 태 를 만 듭 니 다.spring 트 랜 잭 션 에서 catch 가 이상 하 게 되면 spring 의 트 랜 잭 션 이 유효 하지 않 기 때문에 수 동 으로 스크롤 백 하거나 실행 중 이상 을 던 져 서 spring 스크롤 백 방금 동작 을 알려 야 합 니 다.

try{
}catch(Exception e){
    throw new RuntimeException();
}

try{
}catch(Exception e){
    TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
}

상술 한 코드 방법 은 둘 중 하 나 를 선택 하면 된다.
 
스프링 사무 에 관 한 연신 은 스프링 의 사무 에 7 가지 전파 특성 이 있다 는 것 을 알 고 있 기 때문에 일일이 예 를 들 지 않 겠 습 니 다.주로 세 가지 가 헷 갈 릴 수 있다.
1。PROPAGATION_REQUIRED:하나의 사무 가 존재 한다 면 현재 사무 에 가입 합 니 다.트 랜 잭 션 이 없 으 면 열 립 니 다.
2。PROPAGATION_REQUIRES_NEW:항상 새로운 사 무 를 시작 합 니 다.만약 하나의 업무 가 이미 존재 한다 면,이 존재 하 는 사 무 를 걸 어 라. 
3.PROPAGATION_NESTED:하나의 이벤트 가 존재 한다 면 포 함 된 트 랜 잭 션 에서 실 행 됩 니 다.이벤트 가 없 으 면 TransactionDefinition.PROPAGATION 을 누 르 십시오.REQUIRED 속성 실행
첫 번 째 사 무 는 기본 적 인 사무 전파 특성 으로 본 고의 모든 사 무 는 이 를 바탕 으로 한다.   부류 의 방법 이 있 습 니 다.부류 의 방법 은 부류 의 방법 에서 실행 해 야 합 니 다.그러나 부류 와 부류 간 에 서로 독립 할 수 없습니다.부류 나 그 어떠한 부류 에 도 이상 이 발생 하면 스크롤 백 이 필요 합 니 다.
두 번 째 사무 와 첫 번 째 사 무 는 정반 대 이다.각 사무 간 에 서로 독립 된   부류 의 방법 에는 많은 부류 의 방법 이 있 는데 부류 나 그 어떠한 부류 의 방법 에 도 이상 이 발생 하면 이상 이 발생 하 는 방법 에 대해 서 만 스크롤 백 을 할 수 있 고 다른 방법 은 그의 영향 을 받 지 않 는 다.
세 번 째 사 무 는 등급 적 인 관계 이다.     부모 클래스 의 방법 에 이상 이 생 긴 다 면 부모 클래스 에 포 함 된 모든 하위 방법 은 스크롤 백 이 발생 하지만,하위 방법 에 이상 이 생 긴 다 면 부모 클래스 와 다른 하위 방법 은 이상 한 영향 을 받 지 않 고 데이터 정 보 를 스크롤 백 합 니 다.