[MySQL] @Transactional을 붙인 메서드가 롤백되지 않을 때 해결 방법

🚨 Error :

💡 일반적으로 @Transactional 애너테이션을 붙인 메서드 내에 로직 수행 시 문제가 발생하면 데이터베이스에 저장된 데이터가 롤백이 된다. 그런데, 분명 @Transactional 애너테이션을 붙였는데 UnCheckedException이 발생해도 롤백이 되지 않았다.

• 인터넷에 검색해 보면 대부분이 CheckedException이 발생했는데 롤백이 되지 않아 헤맸다는 글이었다.
• 스프링의 @Transactional은 기본적으로 CheckedException을 롤백이 시키지 않는다.
  • 이를 설정하기 위해서는 @Transactional(rollbackFor = Error.class)과 같이 rollback이 적용될 Exception을 커스텀하게 설정해야 한다.

 

문제는 나의 경우에는 RuntimeException도 롤백이 되지 않았다!

문제를 재현하기 위해 테스트 코드를 만들었다.

 

@Service
@RequiredArgsConstructor
public class Service {

    private final ScoutListRepository scoutListRepository;

    public Dto.Response post(Dto.Post post) {
        Player addedPlayer = Player.addPlayer(post.getName(), post.getAge(), post.getTeam(), post.getOverall());

        Player savedPlayer = scoutListRepository.save(addedPlayer);

        return Dto.Response
                .builder()
                .name(savedPlayer.getName())
                .scoutStatus("interested")
                .team(savedPlayer.getTeam())
                .overall(savedPlayer.getOverall())
                .build();
    }
}

• http 요청 바디로 들어온 데이터를 db에 넣는 테스트 코드이다.

 

• postman으로 요청을 보내고 응답을 받았다.

 

• 데이터베이스에 저장까지 잘 된다.

 

@Service
@RequiredArgsConstructor
public class Service {

    private final ScoutListRepository scoutListRepository;

    @Transactional // 트랜잭션 애너테이션 추가
    public Dto.Response post(Dto.Post post) {
        Player addedPlayer = Player.addPlayer(post.getName(), post.getAge(), post.getTeam(), post.getOverall());

        Player savedPlayer = scoutListRepository.save(addedPlayer);

        throw new RuntimeException(); // 고의적으로 UnCheckedException 에러 발생
        
    }
}

• 이제 고의적으로 에러를 발생시켜 트랜잭션 롤백이 정상적으로 수행되는지 테스트해 보자.
• 코드를 수정했다.

 

• 정상적으로 에러가 발생했다.

 

• 롤백이 되지 않고 그대로 들어있다.

🤓 원인 :

• 이 문제를 장기간 해결하지 못했는데 오늘 끝장을 내버리자라는 마음으로 찾아본 결과 해결하게 되었다.
• 일단, 예외 처리 등의 변수를 전부 제외하여 테스트했음에도 롤백이 되지 않았다는 점에서 코드 상에는 문제가 없음을 확신했다.
• 아마도 데이터베이스 자체가 트랜잭션이 적용되지 않는다든가 하는 문제가 아닐까 하는 생각이 들었다.

 

그래서 해당 테이블을 SQL 문으로 추출해 보았다.

 

• ENGINE=MYISAM이 참 낯설었다.
• 보통은 InnoDB였는데 저건 뭐지..? 하며 검색해 본 결과 여러 블로그에서 MYISAM은 속도는 빠르나, 트랜잭션을 기본적으로 지원하지 않으며 MySQL 버전 5.5 이상부터는 Default 엔진이 InnoDB라는 것을 알아냈다.

🚒 해결 :

• 나는 도커 컨테이너에서 mysql 데이터베이스를 돌리고 있었는데 5.7 버전을 사용하고 있음에도 테이블이 MyISAM이었다.
• 이상하다고 생각하고 엔진을 살펴보니 InnoDB가 Default가 맞았다.
• 로컬에서 테스트를 위해 ddl-auto를 create로 돌리고 있었기 때문에 현재 테이블을 생성하는 건 스프링이다.
• 그래서 application.yml을 살펴보았다.

 

• 아.. MySQL5Dialect를 사용했기 때문에 5.5가 아니라서 MyISAM으로 테이블이 만들어진 것 같았다.
  • MySQL57Dialect가 있음으로 5는 그냥 5.0을 의미하는 게 아닌가 싶다.

 

• MySQL5Dialect를 MySQL5InnoDBDialect로 변경하여 InnoDB를 엔진으로 사용하는 것으로 변경하거나, 5.5 이상의 dialect를 사용하면 해결될 것 같았다.
  • 레거시 프로젝트 등의 이유가 아니라면 8로 올리자. 8이 빠르고 안정적이며 좋다.

 

• dialect를 바꾸니 ddl auto create로 생성된 테이블 엔진이 InnoDB로 변경되었다.
• 이제 postman으로 고의적인 RuntimeException을 발생시켜 롤백이 되는지 확인해 보자.

 

정상적으로 롤백이 되었다!

🤔 의문점 :

없음!