늘

프로젝트를 한창 할 당시에는 몰랐었지만 추후에 학습하면서 Event처리를 통해 의존성을 끊는 방법을 알았다. 기존의 공식 프로젝트도 외부 api사용 로직을 분리하고 인터페이스를 통해서 의존성을 많이 줄였다고 생각했는데 여전히 불필요한 의존성이 엮여있었다. 프로젝트가 종료된 후, 해당 문제점을 개선하면서 경험을 포스팅을 해봅니다. 문제 정의 임시 저장 게시글을 등록할 시, 임시 저장 게시글 삭제 로직 아래는 게시글 임시 저장 -> 임시 저장된 게시글을 등록 -> 게시글은 저장되고 임시 저장 글은 제거하는 로직입니다. 해당 로직에서 구체적으로 2가지 문제를 가집니다. Article -> TempArticle의 의존성 생성 게시글을 저장하는 로직에서 임시 저장글이 어떻게 처리 되어야 하는지를 알 필요가 없다고..

스프링의 application context는 Application Event를 제공해준다. 해당 이벤트를 사용할 때 기존 트랜잭션에서 커밋이 된 후에 이벤트를 처리할 때, Transaction의 Propagation을 Requires_new 나 @Asnyc로 주지 않으면 같은 트랜잭션으로 묶여서 정상적으로 이벤트가 발급되지 않는다. 따라서 이벤트에 Propagation.REQUIRES_NEW 옵션을 주어서 사용했는데 이때 Requires_new를 사용한다고 해도 상위 트랜잭션에서 예외를 잡아주지 않으면 예외가 전파되어서 상위 트랜잭션도 롤백이 된다. 따라서 try-catch로 잡아줘야 한다. 그런데.. 실제 event에 대해서 예외 테스트를 진행해줬는데 try-catch로 잡지 않아도 예외가 전파되지 ..

해당 글은 조금 각색해서 우아한테크코스 블로그(테코블)에 있습니다! 트랜잭션을 사용할 때, 아래의 사진처럼 private 메서드에 걸면 컴파일 에러가 나오는 것을 확인할 수가 있다. 인텔리제이가 알려주는 메시지를 보면 private 만 사용하지 않으면 된다고 한다. 이 이유에 대해서는 spring 2.5버전 이후부터는 default로 CGLIB을 사용하므로 상속을 통해 프록시를 구현한다. 하지만 private메서드는 상속이 불가능하기 때문에 프록시를 만들 수 없기 때문이다. 하지만 스프링 공식문서를 보면 public 이외의 모든 메서드는 트랜잭션이 적용되지 않는다고 한다. 실제 protected로 하면 컴파일단에선 예외가 잡히지 않는다. 왜냐하면 프록시는 만들어지기 때문이다. 하지만 스프링 공식문서를 보..

제목에 대한 질문에 답을 하지 못했다.이 질문에 대해서 정리를 해보고자 한다. 그전에 트랜잭션이 무엇인지 정리하고 시작하려고 한다. 트랜잭션이란? 데이터베이스에 작용하는 여러 읽기와 쓰기를 수행하는 하나의 작업 단위 트랜잭션 범위 트랜잭션의 범위는 커넥션을 기준으로 한다. 커넥션이 다르다면 6에서 롤백이 일어나면, 3번과 5번에 해당한 쿼리만 롤백이 된다. 즉, 4번에서 쿼리들은 롤백되지 않고 반영이 된다. 다른 말로, 여러 메서드에서 하나의 트랜잭션을 갖고 싶다면 이 여러 메서드들을 하나의 커넥션을 사용하도록 하는 방법이 필요하다. -> 이러한 방법이 트랜잭션 전파를 사용한다. 트랜잭션 전파 보통 스프링에선 @Transactional을 통해 해당 어노테이션이 선언된 내부 메서드들도 한 커넥션에 묶인다...

1. Transactional(readOnly = true)효과 1.성능상에 이점 readOnly일 경우 트랜잭션 ID를 부여하지 않아 조금의 성능 향상이 있다. 2.안전성 읽기가 아닌 수정하는 동작이 발생하면 TransientDataAccessResourceException 예외를 발생하여 변경을 막아줄 수 있습니다. 그런데 디비에 따라 다르고 Mysql은 위처럼 발생하지만 h2 인메모리 디비에서는 예외가 발생하지 않는다고 한다. 3. 가독성 readOnly가 붙은 메서드는 모두 조회 메서드라는 것을 한 눈에 파악할수 있다는게 장점이다. 예를 들어 프로그램이 커지면 수많은 메서드들이 존재할텐데 그중에서 조회 로직을 수정해야한다면, readOnly가 달린 메서드들만 빠르게 찾아 수정할수 있다는 장점이 있..