Programming/삽질일지

[6/7 TIS] DELETE는 Transactional하게 진행하자.

JKROH 2023. 6. 7. 14:52
반응형

 엔티티를 delete하는 로직을 만들던 중 다음과 같은 에러를 마주했다.

No EntityManager with actual transaction available for current thread - cannot reliably process 'remove' call

대충 보아하니 remove를 안정적으로 할 수 없다는 말이 있었고, transaction이라는 키워드가 눈에 밟혔다.

 

 해당 에러 메세지를 검색해보니 @Transactional 애너테이션을 통해 delete메서드를 수행하는 로직 자체를 트랜잭션 처리하면 삭제가 정상적으로 수행된다고 했다. 그대로 수행했고, 문제 자체는 쉽게 해결했다.

 

 그런데, 왜 삭제 로직은 트랜잭션 처리를 해야하는지가 궁금했다. 삽입, 수정, 조회는 잘 되는데.

 

 라고 생각할 때쯤, 다시 생각해봤다. 그동안 내가 사용한 저장 메서드는 기본 메서드인 save()밖에 없었다. 삭제 메서드는 deleteBy~~()의 형태로 나름의 커스텀을 한 상태였다. 그래서 기본 메서드인 delete(Object param) 메서드를 레포지토리에 만들고 @Transaction 애너테이션을 붙이지 않은 삭제 로직을 수행해봤다. 

 

 결과는 성공적이었다. 삭제가 문제가 아니라, 커스텀이 문제였다. 마찬가지로 save메서드를 어느 정도 커스텀 해봤더니, @Transaction을 요구했다.

 

 API 내부 여러 클래스들을 뜯어보고 내가 생각한 이유는 'CRUD Repository에서 제공해주는 기본 메서드는 자체적으로 트랜잭션 처리가 된다' 였다. (나는 Repository 인터페이스를 사용했는데, 해당 인터페이스에 CRUD Repository를 참고하라고 적혀있더라.)

 

 CRUD 자체가 Transactional 하게 진행되어야 안전하다는 생각은 있었지만, 여러 방법으로 진행해본 경험이 적었기 때문에, 이렇게까지 강요될 줄은 모르고 있었다. 무의식적으로 @Transactional 을 붙이거나 없어도 된다고 생각하는 것이 아니라, 의식적으로 CRUD의 안전한 처리를 위해 트랜잭션 처리를 해주도록 하자.

반응형