- 확인된 예외를 발생시키면 트랜잭션이 정상적으로 롤백되지 않습니다.
- 이유: Spring은 기본적으로 확인되지 않은 예외만 롤백합니다.
RuntimeException和Error
- 해결 방법: rollbackFor 속성 구성
- 이유: Spring은 기본적으로 확인되지 않은 예외만 롤백합니다.
- 비즈니스 메소드의 try-catch 예외로 인해 트랜잭션을 올바르게 롤백할 수 없음
이유: 트랜잭션 알림은 대상에서 throw된 예외가 catch된 경우에만 후속 롤백 처리를 수행할 수 있습니다. 대상이 예외를 자체적으로 처리하는 경우 트랜잭션 알림 알 수 없음- 해결 방법 1: 예외가 있는 그대로 throw됩니다.
- 해결 방법 2: TransactionStatus.setRollbackOnly()를 수동으로 설정
- AOP 측면의 순서는 트랜잭션의 잘못된 롤백으로 이어집니다.
- 이유: 트랜잭션 aspect의 우선순위는 가장 낮으나 custom aspect의 우선순위가 같으면 여전히 custom aspect의 inner layer이다. 올바르게 하면 트랜잭션이
실패 하게 됩니다. - 솔루션: 사례 2와 동일
- 이유: 트랜잭션 aspect의 우선순위는 가장 낮으나 custom aspect의 우선순위가 같으면 여전히 custom aspect의 inner layer이다. 올바르게 하면 트랜잭션이
- 비공개 방식으로 인한 트랜잭션 무효화
- 이유: Spring은 메서드에 대한 프록시를 생성하고 트랜잭션 알림을 추가하며 전제 조건은 메서드가 공개라는 것입니다.
- 솔루션: 공개 방법으로 변경
- 이 클래스 메서드를 호출하면 전파 동작이 실패합니다.
- 이유: 이 클래스의 메서드 호출은 프록시를 거치지 않아 강화가 불가능하다 같은 클래스에 있는 두 개의 메서드가 A, B이고 메서드 A에 트랜잭션 주석이 추가되지 않은 경우 @Transactional 트랜잭션 메서드 B에 주석이 추가되고 메서드 A가 메서드 B를 호출하면 메서드 B의 트랜잭션이 무효화됩니다.
- 솔루션 1: 의존성 주입 자체(프록시) 호출
- 해결 방법 2: AopContext를 통해 프록시 개체를 가져오고 호출합니다.
- @Transactional 메서드로 인한 동기 무효화
- 이유: 동기화는 대상 메서드의 원자성만 보장하며 대상 메서드를 둘러싼 커밋과 같은 작업이 있습니다. 그들이 아직 커밋하지 않았을 가능성이 높습니다.
- 해결 방법: 업데이트를 위해 select ...를 사용하여 select를 대체합니다.
- 최종 수정 방법으로 인해 트랜잭션이 실패합니다.
- 이유: 스프링 트랜잭션의 맨 아래 레이어는 aop를 사용합니다. 즉, jdk 동적 프록시 또는 cglib를 통해 프록시 클래스를 생성하고 프록시 클래스에서 트랜잭션 기능을 구현하는 데 도움이 됩니다. 그러나 메소드가 final로 수정되면 해당 프록시 클래스에서 트랜잭션 기능을 추가하기 위해 메소드를 다시 작성할 수 없습니다.
Spring 트랜잭션 실패 시나리오에 대한 자세한 설명
Supongo que te gusta
Origin blog.csdn.net/TangBoBoa/article/details/130412305
Recomendado
Clasificación