Spring 트랜잭션(둘) - 트랜잭션의 전파 동작

유래
'사무의 전파 행위'는 듣기에 매우 고상한 느낌을 준다.사실 지난 편의 사무 회고도 이것을 깔기 위한 것이다. 우리는 사무가 어떻게 된 일인지 이미 알고 있지만 이 개념을 코드로 진정으로 전환해야 한다.우리는 코드를 쓸 때 모두 controller, 서비스,dao 세 층이 있다는 것을 알고 있다. 요청이 오면 먼저 controller에 도착한 다음에 controller는 서비스, 서비스를 호출하고dao를 호출한다.
업무 장면① 서비스1에 Hello 방법이 있다고 가정하면 그 안에는dao1의 Hello1 방법과 dao2의 Hello2 방법이 각각 호출된다.

service1{
	serviceHello1(){
		dao1.daoHello1();
		dao2.daoHello2();
	}
}

이런 상황은 매우 흔하다. 서비스층 서비스Hello1 방법에 사무A를 추가하면 된다.이렇게 하면 DaoHello1과 daoHello2 방법이 업무의 4대 특성을 동시에 만족시킬 수 있다.
② 서비스 2가 존재한다고 가정하면 그 안에 서비스 Hello2 방법이 있는데 그 안에는 Dao3의daoHello3 방법과 dao4의daoHello4 방법을 각각 사용했다.

service2{
  	serviceHello2(){
  		dao3.daoHello3();
  		dao4.daoHello4();
  	}
}

가령 ②와 가령 ①와 마찬가지로 서비스 2층 서비스Hello2 방법에 하나의 업무 B를 추가하면 된다.이렇게 하면 DaoHello3과 daoHello4 방법이 업무의 4대 특성을 동시에 만족시킬 수 있다.
③ 현재 서비스 3이 있다고 가정하면 그의 업무는 상대적으로 복잡하다. 서비스 3의 서비스 Hello3 방법은 서비스 1과 서비스 2의 방법을 동시에 호출해야 한다.

service3{
	serviceHello3(){//  C
    	service1.serviceHello1();//  A
    	service2.serviceHello2();//  B
	}
}

이제 문제가 생겼습니다. 서비스 Hello3 방법에 하나의 사무 C를 추가했습니다. 그러면 사무 A, B, C는 하나의 사무를 공용할 수 있습니까?아니면 서비스 Hello2 방법은 업무 B를 전혀 추가하지 않았는데, 업무 C를 직접 사용할 수 있습니까?등등.. 이런 여러 가지 상황은 하나의 기준을 통일시켜야 한다.그래서 사무의 전파 행위가 탄생했다!
Spring의 7가지 트랜잭션 전파 행위 (중점 ①④ ⑥)
트랜잭션 전파 동작 유형
설명
① PROPAGATION_REQUIRED
현재 업무를 지원합니다. 존재하지 않으면 하나를 만듭니다.
② PROPAGATION_SUPPORTS
현재 사무를 지원합니다. 존재하지 않으면 사무를 사용하지 않습니다
③ PROPAGATION_MANDATORY
현재 업무를 지원합니다. 존재하지 않으면 이상을 던집니다.
④ PROPAGATION_REQUIRES_NEW
만약 사무가 존재한다면, 현재 사무를 닫고 새 사무를 만듭니다
⑤ PROPAGATION_NOT_SUPPORTED
비사무적으로 실행되며, 사무가 존재하면 현재 사무를 종료합니다
⑥ PROPAGATION_NEVER
비사무적으로 실행되며, 사무가 존재하면 이상을 던집니다
⑦ PROPAGATION_NESTED
현재 업무가 존재하면, 플러그인 업무 실행
서비스 3의 예를 참조하십시오.

service3{
  	serviceHello3(){//  C
    	service1.serviceHello1();//  A
    	service2.serviceHello2();//  B
  	}
}

PROPAGATION_REQUIRED ① 트랜잭션 C가 있는 경우: PROPAGATIONREQUIRED가 수식한 서비스Hello1()과 서비스Hello2()는 서비스Hello3()의 사무에 모든 Propagation에 가입합니다.REQUIRED 수식의 내부 방법과 외곽 방법은 모두 같은 업무에 속하는데 한 방법만 굴러가면 전체 업무가 굴러간다.② 트랜잭션 C가 존재하지 않는 경우: PROPAGATIONREQUIRED가 수식한 서비스 헬로1()과 서비스 헬로2()는 자신의 사무 A와 사무 B를 새로 열고 사무 A와 사무 B가 서로 독립하며 서로 간섭하지 않는다.즉, 사무A는 서비스헬로1()에 이상이 생기면 굴러가고, 사무B는 서비스헬로2()에 이상이 생기면 굴러가는 것만 보장할 수 있다.서비스헬로3() 예외가 발생하면 롤백되지 않습니다.
PROPAGATION_REQUIRES_NEW ① 트랜잭션 C가 있는 경우: Propagation.REQUIRES_NEW가 수식한 서비스헬로1(서비스헬로2)과 서비스헬로2()는 여전히 사무 A와 사무 B를 단독으로 열고 외부 방법의 사무 C와도 독립하며 내부 방법과 외부 방법의 사무는 서로 독립되고 서로 간섭하지 않는다.② 트랜잭션 C가 존재하지 않는 경우: Propagation.REQUIRES_NEW가 수식한 서비스헬로1(serviceHello1)과 서비스헬로2(serviceHello2)는 자신의 사무A와 사무B를 새로 열고 사무A와 사무B가 서로 독립하며 서로 간섭하지 않는다.즉, 사무A는 서비스헬로1()에 이상이 생기면 굴러가고, 사무B는 서비스헬로2()에 이상이 생기면 굴러가는 것만 보장할 수 있다.서비스헬로3() 예외가 발생하면 롤백되지 않습니다.
PROPAGATION_NESTED ① 트랜잭션 C가 있는 경우: Propagation.NESTED로 장식된 서비스Hello1()과 서비스Hello2()(사무 A와 사무 B)는 외부 사무 C의 하위 사무에 속하고 외부 사무 C는 굴러간다. 하위 사무 A와 B는 반드시 굴러간다. 내부 하위 사무 A와 B는 외부 사무 C와 다른 하위 사무에 영향을 주지 않고 단독으로 굴러갈 수 있다.
② 트랜잭션 C가 없는 경우: Propagation.NESTED 및 Propagation.REQUIRED의 역할이 같고 수식된 내부 방법은 모두 자신의 사무 A와 사무 B를 새로 열고 사무 A와 사무 B는 서로 독립하며 서로 간섭하지 않는다.