코드를 작성하면서 @Transactional, @Transactional(read=only)를 붙이는 이유에 대해서 학습해보고자 하여 정리한다.
Transactional
데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 모두 수행되어야 할 일련의 연산들을 의미한다.
즉, DB의 논리적 연산 단위로써 하나의 연산을 처리하는 일련의 과정을 말한다.
트랜잭션의 특성에 대해서는 다루지 않겠다. (ACID에 대해 찾아보길)
@Transactional(readonly = true)
@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class MemberService {
...
}다음과 같이 해당 서비스에 동작하는 위에 해당 어노테이션을 달아주었다.
이것은 무엇을 의미할까?
이 Service Class에 작성되는 모든 메서드들에 @Transactional(readOnly = true) 를 적용시켜준다.
그렇다면 이것을 붙이는 이유는 무엇일까?
대부분 생각을 하자면 DB에서 읽기 기능만 수행되는 경우 쓰기 작업이 수행되지 않아서 해당 어노테이션을 붙이면 성능상 이점을 얻을 수 있는 것으로 알고 있다.
그렇다면 성능상 이점을 어떻게 얻을 수 있을까?
- JPA의
@Transactional(readOnly = true)는 하이버네이트의Session의FlushMode를FlushMode.MANUAL로 설정한다. - 이로 인해, 명시적으로 플러시를 호출하지 않는 한 자동으로 플러시가 일어나지 않는다.
- 즉, 엔티티 매니저가 영속성 콘텍스트의 상태를 데이터베이스에 자동으로 동기화하지 않게 된다.
- 해당 어노테이션을 통해 JPA에게 읽기 작업만을 수행하는 것을 알려준다.
- 더티 체킹에 대한 내용은 아래에서 다루도록 한다.
Dirty Checking
@Transactional 어노테이션이 작성되었을 때 동작한다.
@Transactional(readOnly = true)가 설정되면, JPA는 더티 체킹(Dirty Checking)를 비활성화한다.- 따라서, 엔티티 상태의 변경 감지를 위한 스냅샷을 유지하지 않으며, 이로 인해 성능이 개선될 수 있다.
더티 체킹을 하지 않아 스냅샷을 찍지 않게 되면 메모리상으로도 이점을 얻을 수 있다.
JPA에서는 더티체킹(Dirty Checking)이라는 기능이 있어 객체의 값이 수정될 경우 save() 메서드를 사용하지 않아도 값이 DB에 수정되어 저장된다.
- 엔티티 상태 변경 감지:
@Transactional이 없으면, 엔티티 매니저가 해당 트랜잭션의 범위 내에서 상태를 추적하지 않기 때문에 변경된 상태를 감지하지 못할 수 있다. - 변경 사항의 반영: 트랜잭션이 없으면, 엔티티 매니저는 변경 사항을 플러시(flush)할 시점을 알 수 없으므로, 변경된 내용을 데이터베이스에 반영하지 않을 수 있다.
- JPA에서는 트랜잭션이 끝나는 시점에 Flush를 날려 변화가 생긴 모든 값들을 DB에 적용시킨다.
@Transactional Update 로직에서의 save()
궁금증이 생겼다.
나의 경우 코드를 작성할 때 @Transacional 어노테이션이 붙은 메서드에 한해 더티체킹이 일어난다는 사실을 알고 있으나 update로직을 작성할 때 명시적으로 save()를 붙여준다.
같이 개발을 하고있는 지인은 붙이지 않는다고 한다.
이 둘에 대한 차이점을 다음 글에서 다뤄보도록 하겠다.
학습 참조: https://velog.io/@sweet_sumin/Transactional%EC%9D%84-%EC%93%B0%EB%8A%94-%EC%9D%B4%EC%9C%A0%EB%8A%94
