봄의 거래 전파 행동을 깊이 이해합니다

머리말

Spring은 TransactionDefinition 인터페이스에서 7 가지 유형의 트랜잭션 전파 동작을 지정합니다. 거래 전파 동작은 Spring Framework에 고유 한 트랜잭션 향상 기능이며 거래 실제 공급자의 데이터베이스 동작에 속하지 않습니다. 이것은 Spring이 우리에게 제공하는 강력한 도구 상자이며, 트랜잭션 전파 라인을 사용하면 개발 노력에 많은 편의를 제공 할 수 있습니다. 그러나 사람들은 그것에 대해 많은 오해를 가지고 있으며, "서비스 방법 사업이 중첩되지 않는 것이 가장 좋다"는 소문을 들었을 것입니다. 도구를 올바르게 사용하려면 먼저 도구를 이해해야합니다. 이 기사는 7 가지 트랜잭션 전파 동작을 자세히 소개하고 컨텐츠의 주요 코드 예를 제시합니다.

기본 개념

1. 트랜잭션 커뮤니케이션 동작이란 무엇입니까?

트랜잭션 전파 동작은 특정 트랜잭션 전파 동작에 의해 수정 된 메소드가 다른 방법에 중첩 될 때 트랜잭션이 전파되는 방법을 설명하는 데 사용됩니다.

의사 코드를 사용하여 다음을 설명하십시오.

 public void methoda () {methodb (); // dosomething} @transaction (propagation = xxx) public void methodb () {// dosomething}

코드의 methodA() 메소드는 중첩으로 methodB() 메소드를 호출하고 methodB() 의 트랜잭션 전파 동작은 @Transaction(Propagation=XXX) 설정에 의해 결정됩니다. 여기서 methodA() 가 트랜잭션을 시작하지 않으며, 특정 트랜잭션 전파 동작을 수정하는 방법은 트랜잭션을 시작하는 주변 방법에서 호출 될 필요가 없음을 주목해야합니다.

2. 봄의 7 가지 거래 전파 행동

정의는 매우 간단하고 이해하기 쉽습니다. 우리의 이해가 올바른지 확인하려면 코드 테스트 섹션으로 이동합시다.

코드 확인

이 기사의 코드는 전통적인 3 층 구조, 즉 서비스 및 DAO 계층의 두 층으로 표시됩니다. Spring은 의존성 주입 및 주석 거래 관리를 담당합니다. DAO 층은 Mybatis에 의해 구현됩니다. Hibernate, JPA, JDBCTemplate 등과 같은 좋아하는 방법을 사용할 수도 있습니다. 데이터베이스는 MySQL 데이터베이스를 사용하며 모든 트랜잭션 가능 데이터베이스를 사용하여 확인 결과에 영향을 미치지 않습니다.

먼저 데이터베이스에서 두 개의 테이블을 만듭니다.

user1

 테이블 작성`user1` (`id` integer signged not null auto_increment,`name` varchar (45) null default not default '', 기본 키 (`id`)) 엔진 = innodb;

user2

 테이블 작성`user2` (`id` integer signged not null auto_increment,`name` varchar (45) null default not default '', 기본 키 (`id`)) 엔진 = innodb;

그런 다음 해당 Bean 및 DAO 레이어 코드를 작성하십시오.

user1

 공개 클래스 사용자 1 {개인 정수 ID; 개인 문자열 이름; // 메서드를 얻고 설정하면 생략됩니다 ...}

user2

 공개 클래스 user2 {개인 정수 ID; 개인 문자열 이름; // 메서드를 얻고 설정하면 생략됩니다 ...}

user1mapper

 공개 인터페이스 user1mapper {int insert (user1 record); user1 selectByPrimaryKey (정수 ID); // 다른 방법이 생략되었습니다 ...}

user2mapper

 공개 인터페이스 user2Mapper {int insert (user2 record); user2 selectByPrimaryKey (정수 ID); // 다른 방법이 생략되었습니다 ...}

마지막으로, 특정 검증 코드는 서비스 계층에 의해 구현되며 다음 상황에서 나열합니다.

1. propagation_required

user1service 및 user2service의 해당 메소드에 대한 Propagation.REQUIRED 추가합니다.

user1service 메소드 :

 @ServicePublic Class user1ServiceImpl user1Service {// 다른 사람을 생략합니다 ... @OverRide @transactional (propagation = propagation.Required) public void addRequired (user1 user) {user1mapper.insert (user); }}

user2Service 메소드 :

 @ServicePublic Class user2ServiceImpl은 user2Service를 구현합니다. {// 기타 ... @OverRide @transactional (propagation = propagation.Required) public void addRequired (user2 user) {user2mapper.insert (user); } @override @transactional (propagation = profagation.required) public void addRequiredException (user2 user) {user2mapper.insert (user); 새로운 runtimeexception ()을 던지십시오. }}

1.1 장면 1

이 시나리오 주변 장치 방법은 트랜잭션을 활성화하지 않습니다.

검증 방법 1 :

 @override public void nottransaction_exception_required_required () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addrequired (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addrequired (user2); 새로운 runtimeexception ()을 던지십시오. }

검증 방법 2 :

 @override public void nottransaction_required_required_exception () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addrequired (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addrequiredException (user2); }

검증 방법을 개별적으로 실행하고 결과를 실행하십시오.

검증 방법 일련 번호 데이터베이스 결과 분석

결론 :이 두 가지 방법을 통해, 우리는 전파에 의해 수정 된 내부 방법이 주변 장치가 거래를 열지 않을 때 새로 자체 트랜잭션을 개방하고 개방 된 트랜잭션이 서로 독립적이며 서로 방해받지 않는다는 것을 증명합니다.

1.2 장면 2

주변 장치는 거래를 시작하는데, 이는 상대적으로 높은 사용률을 가진 시나리오입니다.

검증 방법 1 :

 @override @transactional (propagation = profagation.required) public void transaction_exception_required_required () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addrequired (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addrequired (user2); 새로운 runtimeexception ()을 던지십시오. }

검증 방법 2 :

 @override @transactional (propagation = profagation.required) public void transaction_required_required_exception () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addrequired (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addrequiredException (user2); }

검증 방법 3 :

 @transactional @override public void transaction_required_required_exception_try () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addrequired (user1); user2 user2 = new user2 (); user2.setname ( "li si"); try {user2service.addrequiredException (user2); } catch (예외 e) {System.out.println ( "메소드 롤백"); }}

검증 방법을 개별적으로 실행하고 결과를 실행하십시오.

결론 : 위의 실험 결과는 주변 방법이 트랜잭션을 열면 Propagation.REQUIRED 에 의해 수정 된 내부 방법이 주변 장치의 트랜잭션에 추가 될 것임을 보여줍니다. Propagation.REQUIRED 에 의해 수정 된 모든 내부 방법 및 주변 방법은 동일한 트랜잭션에 속합니다. 하나의 메소드가 롤백하는 한 전체 트랜잭션이 롤백됩니다.

2.Propagation_Requires_new

user1service 및 user2service의 해당 메소드에 대한 Propagation.REQUIRES_NEW 추가합니다.

user1service 메소드 :

 @ServicePublic Class user1ServiceImpl user1Service {// 기타를 생략합니다 ... @OverRide @transactional (propagation = propagation.Requires_New) public void addRequiresNew (user1 user) {user1mapper.insert (user); } @override @transactional (propagation = profagation.required) public void addRequired (user1 user) {user1mapper.insert (user); }}

user2Service 메소드 :

 @ServicePublic Class user2ServiceImpl은 user2Service를 구현합니다 {// 다른 사람을 생략합니다 ... @Override @transactional (propagation = propagation.requires_new) public void addRequiresNew (user2 user) {user2mapper.insert (user); } @override @transactional (propagation = profagation.requires_new) public void addRequiresNewException (user2 user) {user2mapper.insert (user); 새로운 runtimeexception ()을 던지십시오. }}

2.1 장면 1

주변 장치는 트랜잭션을 활성화하지 않습니다.

검증 방법 1 :

 @override public void nottransaction_exception_requiresnew_requiresnew () {user1 user1 = new User1 (); user1.setName ( "Zhang San"); user1service.addrequiresnew (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addrequiresnew (user2); 새로운 runtimeexception ()을 던지십시오. }

검증 방법 2 :

 @override public void nottransaction_requiresnew_requiresnew_exception () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addrequiresnew (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addrequiresnewexception (user2); }

검증 방법을 개별적으로 실행하고 결과를 실행하십시오.

결론 :이 두 가지 방법을 통해, 우리는 Propagation.REQUIRES_NEW 에 의해 수정 된 내부 방법이 새로 자체 트랜잭션을 시작하고 열린 거래는 서로 독립적이며 서로 방해하지 않는다는 것을 증명합니다.

2.2 장면 2

주변 장치는 거래를 시작합니다.

검증 방법 1 :

 @override @transactional (propagation = profagation.required) public void transaction_exception_required_requiresnew_requiresnew () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addrequired (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addrequiresnew (user2); user2 user3 = new user2 (); user3.setName ( "Wang Wu"); user2service.addrequiresnew (user3); 새로운 runtimeexception ()을 던지십시오. }

검증 방법 2 :

 @override @transactional (propagation = profagation.required) public void transaction_required_requiresnew_requiresnew_exception () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addrequired (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addrequiresnew (user2); user2 user3 = new user2 (); user3.setName ( "Wang Wu"); user2service.addrequiresnewexception (user3); }

검증 방법 3 :

 @override @transactional (propagation = profagation.required) public void transaction_required_requiresnew_requiresnew_exception_try () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addrequired (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addrequiresnew (user2); user2 user3 = new user2 (); user3.setName ( "Wang Wu"); try {user2service.addrequiresnewexception (user3); } catch (예외 e) {System.out.println ( "Rollingback"); }}

검증 방법을 개별적으로 실행하고 결과를 실행하십시오.

결론 : 주변 메소드가 트랜잭션을 열면 Propagation.REQUIRES_NEW 에 의해 수정 된 내부 메소드는 여전히 독립 트랜잭션을 개별적으로 개방하며 외부 메소드 트랜잭션과도 무관합니다. 내부 방법, 내부 방법 및 외부 메소드 트랜잭션은 서로 독립적이며 서로를 방해하지 않습니다.

3. propagation_nested

user1service 및 user2service의 해당 메소드에 Propagation.NESTED 속성을 추가합니다.

user1service 메소드 :

 @ServicePublic Class user1ServiceImpl은 user1service {// 다른 ... @override @transactional (propagation = propagation.nested) public void addnested (user1 user) {user1mapper.insert (user); }}

user2Service 메소드 :

 @ServicePublic Class user2ServiceImpl은 user2Service를 구현합니다. {// 기타를 생략합니다 ... @Override @Transactional (propagation = propagation.nested) public void addnested (user2 user) {user2mapper.insert (user); } @override @transactional (propagation = propagation.nested) public void addnestedexception (user2 user) {user2mapper.insert (user); 새로운 runtimeexception ()을 던지십시오. }}

3.1 장면 1

이 시나리오 주변 장치 방법은 트랜잭션을 활성화하지 않습니다.

검증 방법 1 :

 @override public void nottransaction_exception_nested_nested () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addnested (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addnested (user2); 새로운 runtimeexception ()을 던지십시오. }

검증 방법 2 :

 @override public void nottransaction_nested_nested_exception () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addnested (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addnestedException (user2); }

검증 방법을 개별적으로 실행하고 결과를 실행하십시오.

결론 :이 두 가지 방법을 통해, 우리는 Propagation.NESTED 와 Propagation.REQUIRED 주변 장치가 트랜잭션을 열지 않을 때 동일한 기능을 가지고 있음을 증명합니다. 수정 된 내부 방법은 자체 트랜잭션을 다시 시작하며 개방 된 거래는 서로 독립적이며 서로를 방해하지 않습니다.

3.2 장면 2

주변 장치는 거래를 시작합니다.

검증 방법 1 :

 @transactional @override public void transaction_exception_nested_nested () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addnested (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addnested (user2); 새로운 runtimeexception ()을 던지십시오. }

검증 방법 2 :

 @transactional @override public void transaction_nested_nested_exception () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addnested (user1); user2 user2 = new user2 (); user2.setname ( "li si"); user2service.addnestedException (user2); }

검증 방법 3 :

 @transactional @override public void transaction_nested_nested_exception_try () {user1 user1 = new user1 (); user1.setName ( "Zhang San"); user1service.addnested (user1); user2 user2 = new user2 (); user2.setname ( "li si"); try {user2service.addnestedexception (user2); } catch (예외 e) {System.out.println ( "메소드 롤백"); }}

검증 방법을 개별적으로 실행하고 결과를 실행하십시오.

결론 : 위의 테스트 결과는 주변 장치가 트랜잭션을 열면 Propagation.NESTED 에 의해 수정 된 내부 방법이 외부 트랜잭션의 하위 전환에 속함을 보여줍니다. 주변 기본 트랜잭션은 롤백되며 하위 전환은 롤백해야합니다. 내부 하위 전환은 주변 기본 거래 및 기타 하위 전환에 영향을 미치지 않고 별도로 롤백 할 수 있습니다.

4. 필수의 유사성과 유사성, Emply_new, 중첩

"1.2 Scene 2"와 "3.2 Scene 2"의 비교에서 다음을 볼 수 있습니다.

중첩 및 필수로 수정 ​​된 내부 방법은 주변 방법 트랜잭션입니다. 주변 장치가 예외를 던지면 두 방법의 트랜잭션이 롤백됩니다. 그러나 필수 조인 주변 방법 트랜잭션이 있으므로 주변 거래와 동일한 트랜잭션에 속합니다. 필요한 트랜잭션이 예외가 발생하고 롤백되면 주변 메소드 트랜잭션도 롤백됩니다. 중첩은 주변 장치의 하위 전환이며 별도의 저장 포인트가 있으므로 중첩 방법은 예외를 던지고 롤백되므로 주변 장치의 트랜잭션에는 영향을 미치지 않습니다.

"2.2 Scene 2"와 "3.2 Scene 2"의 비교에서 다음을 볼 수 있습니다.

중첩 및 요구 사항 모두 주변 메소드 트랜잭션에 영향을 미치지 않고 내부 메소드 트랜잭션을 롤백 할 수 있습니다. 그러나 중첩은 중첩 트랜잭션이기 때문에 주변 장치 방법이 롤백 된 후 주변 방법 트랜잭션 인 하위 전환도 롤백됩니다. 요구_New는 새로운 트랜잭션을 열어 구현됩니다. 내부 거래 및 주변 거래는 두 가지 거래입니다. 주변 거래 롤백은 내부 거래에 영향을 미치지 않습니다.

5. 다른 거래 전파 행동

기사의 길이 문제를 고려할 때, 다른 거래 전파 행동의 테스트는 여기에 설명되지 않습니다. 관심있는 독자는 소스 코드에서 해당 테스트 코드 및 결과 설명을 검색 할 수 있습니다. 포털 : https : //github.com/tmtse/tran ...

시뮬레이션 사용 사례

많은 트랜잭션 커뮤니케이션 동작을 도입 한 후 실제 작업에 어떻게 적용합니까? 예를 들어 보겠습니다.

포인트를 추가하는 방법이 호출되는 등록 된 메소드가 있다고 가정합니다. 등록 프로세스에 영향을 미치지 않도록 포인트를 추가하려면 (즉, 롤백이 점수를 추가하지 못한 경우 등록 메서드 롤백도 만들 수 없습니다).

 @service public class usererviceimpl은 userervice {@transactional public void register (user user) {try {membershippointservice.addpoint (point point); } catch (예외 E) {// 생략 ...} // 생략 ...} // 생략 ...}

또한 등록 실패는 addPoint() 메소드 (등록 메소드 롤백에도 롤백이 필요하다)에 영향을 미칠 것이라고 규정하므로 다음과 같이 addPoint() 메소드를 구현해야합니다.

 @service public class 멤버시 멤버시 핀트 erviceimpl은 멤버시 포인트 서비스 {@transactional (propagation = propagation.nested) public void addpoint (point point) {try {recordservice.addrecord (레코드 레코드); } catch (예외 E) {// 생략 ...} // 생략 ...} // 생략 ...}

addRecord() addPoint() 것을 알았습니다. 그의 구현은 다음과 같습니다.

 @service public class recordserviceimpl은 Recordservice {@transactional (propagation = propagation.not_supported) public void addrecord (레코드 레코드) {// avit ...} // avit ...}

addRecord() 메소드에서 propagation = Propagation.NOT_SUPPORTED 로그에 정확하지 않기 때문에 addRecord () 메소드 자체와 Peripheral addPoint() addRecord() () 메서드가 롤백으로 되돌릴 수 없기 때문에 addRecord() 메소드에 지원되지 않았 음을 알았습니다. addRecord() 메소드가 addPoint() 메소드를 유발하지 않습니다.

이 예를 통해 모든 사람이 트랜잭션 커뮤니케이션 행동 사용에 대해보다 직관적 인 이해를 가지고 있다고 생각합니다. 다양한 속성의 조합은 실제로 비즈니스 구현을보다 유연하고 다양하게 만들 수 있습니다.

결론적으로

위의 소개를 통해 모든 사람이 봄 거래 커뮤니케이션 행동에 대해 더 깊이 이해하고 있다고 생각하며, 매일의 개발 작업이 도움이되기를 바랍니다.

요약

위는이 기사의 전체 내용입니다. 이 기사의 내용에 모든 사람의 연구 나 작업에 대한 특정 참조 가치가 있기를 바랍니다. 궁금한 점이 있으면 의사 소통을 위해 메시지를 남길 수 있습니다. Wulin.com을 지원 해주셔서 감사합니다.