커밋 이전/이후에 추가적인 작업을 진행하고 싶을 때가 있다. @Transactional fun test() { TransactionSynchronizationManager.registerSynchronization(object : TransactionSynchronizationManager(), TransactionSynchronization { override fun afterCommit() { // ... 로직 } }) // ... db 작업 시작 } 트랜잭션 시작하는 메소드 맨 위에 위와 같이 TransactionSynchronizationManager.registerSynchronization를 사용하면 된다. TransactionSynchronization 에서 다양한 메소드가 있으니 본인이 필..
🙄서론 트랜잭션에 있는 readOnly가 읽기전용모드로서 cud가 발생하게 되면 에러를 뱉어주고, 읽기만 가능한 기능으로 알고 있었다. 그런데, 왜 성능향상에도 도움이 되는가에 대해선 자세히 몰라서 알아보았다. 😎본론 @Transactional(readOnly = true) 트랜잭션에서 readOnly=true 라는 옵션을 설정한다. FlushMode 를 MANUAL로 변경하여 dirty checking(변경감지) 을 생략한다. flush와 commit이 일어나지 않고, 이로 인해 영속성 컨텍스트에서는 스냅샷을 보관하지 않아 약간의 성능향상이 이루어지는 것. 크게 눈에 띄게 성능향상이 이루어지지는 않는다고 한다. 보통 사용하는 이유로는 해당 메소드가 변경이 되면 안되고, 조회하는 걸 명확하게 명시해주기 ..
😗서론 @Transactional 어노테이션과 synchronized을 동시에 사용하고 싶은 경우가 있을 수 있다. 트랜잭션 격리수준과 별개로 해당 메소드를 동기화를 적용시키고 싶을 때. 하지만, 한 메소드 위에 해당 Transactional, Synchronized를 동시에 적용 시 원하는대로 작동하지 않을 수 있다. 그 이유를 알아보자. 😎본론 아래 예시는 스택오버플로우를 번역하여 풀어서 정리했습니다. 🤨뭐가 문제지? 일단 Synchronized를 사용하는 이유는 해당 메소드를 한 쓰레드에서만 돌리기 위해서다. 하지만, 트랜잭션이 같이 정의가 되어있다면 첫 번째 쓰레드가 끝나기 전 두 번째 쓰레드가 발동할 수도 있다. 그 이유를 살펴보자. @Transactional public synchronized..
😎본론 로직을 구현하다가 아래와 같은 상황을 마주한 적이 있었다. 트랜잭션 내에서 쿼리작업을 진행하다가 validation을 통해 걸렸을 때 에러는 발생하지 않고, 지금까지 변경된 쿼리를 롤백을 시켜야 할 떄 @Transactional 은 Exception 이 발동할 때만 롤백을 시킨다. 🤔그러면 어떻게 롤백을 시켜야할까? TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); 트랜잭션이 롤백하는 방법을 강제적으로 넣어주는 것이다. setRollbackOnly 을 통해 트랜잭션이 종료되었을 때 무조건 롤백을 시키도록 설정하는 것이다. 물론 해당 로직은 리팩토링 작업을 통해 validation과 쿼리작업을 분리하였다. 당장 테스트를 해..
😅서론 상속받은 클래스 내에 @Transactonal 이 걸려있는 삭제 메소드가 트랜잭션이 발동을 안 하는 버그를 발견했다. 같은 클래스 내에서 프록시가 발동하지 않는다는 것은 알고 있었지만, 막상 겪으니 다른 클래스인데 뭐가 문제지..? 란 생각에 빠져서 찾는 대에 시간을 좀 사용했다.. 그 김에 작성.. 😁본론 스프링은 AOP를 하기위해 기본적으로 디자인패턴인 프록시패턴을 채택하여 사용하고 있다. AOP(Aspect Oriented Programming) 관점지향 프로그래밍이라는 뜻으로 여러 곳에서 사용되는 공통된 로직을 모듈화하여 비즈니스 로직에서 분리시켜준다. 이로써 우리는 비즈니스 로직 외에 부가적인 로직은 따로 외부에서 관리하여 유지보수 및 재사용성이 용이해진다. 프록시(Proxy) 스프링의 ..
