@Transactional(readOnly = true)

@Transactional(readOnly = true)를 붙이는 이유

스프링AOP를 통해서 @Transactional 어노테이션만으로 Service 계층에서 트랜잭션을 걸 수있다.
일반적으로 조회용 메서드에는 @Transactional(readOnly = true)를 설정함으로써 성능상 이점? 을 얻을 수 있다고 한다.
그렇다면 왜 그런것일까?
- 기본적으로 영속성 컨텍스트는 Entity 조회시 상태에 대한 Snapshot을 저장한다. 처음에 초기상태의 정보를 가지는 Snapshot과 Entity의 상태를 비교하여 update query를 생성해 쓰기 지연 저장소에 보관하게 된다.
- 그 후에 일괄적으로 쓰기 지연 저장소에 저장되어있는 SQL query를 flush 하고 데이터베이스의 트랜잭션을 Commit 함으로써 update같은 메서드를 사용하지 않고 Entity의 수정이 이루어지게된다. 이를 변경감지(Dirty Checking) 이라고 한다.
- 이 때 readOnly = true를 설정하게 되면 JPA의 세션 플러시 모드를 MANUAL로 설정한다.
  - MANUAL 모드는 트랜잭션 내에서 사용자가 수동으로 flush를 호출하지 않는이상 flush가 자동으로 수행되지 않는다. 즉, 수정내역이 DB에 반영되지 않는 것이다.
- 이로인해 트랜잭션 Commit시 영속성 컨텍스트가 자동으로 flush되지 않으므로 조회용으로 가져온 Entity의 예상치 못한 수정을 방지 할 수 있다. (영속성 컨텍스트에 담긴 Entity가 수정되어도 DB에 반영되지 않기때문)
- 또한 readOnly = true를 설정하게 되면 JPA는 해당 트랜잭션 내에서 조회하는 Entity는 조회용임을 인식하고 변경감지를 위한 Snapshot을 따로 보관하지 않으므로 메모리가 절약되는 성능상 이점이 존재한다.
@Transactional(readOnly = true)를 왜 붙여야 하나요

@Transactional 을 붙이지 않는 것과 @Transactional(readOnly=true) 차이

특징	`@Transactional` 없음	`@Transactional(readOnly = true)`
트랜잭션 생성 여부	❌ 없음	✅ 읽기 전용 트랜잭션 생성
영속성 컨텍스트 유지 여부	❌ 없음 (즉시 종료)	✅ 유지됨 (트랜잭션 범위 내에서)
Dirty Checking 작동 여부	❌ 작동 안 함 (컨텍스트가 없음)	❌ 작동 안 함 (readOnly=true로 인해 비활성화)
flush() 실행 여부	❌ 실행되지 않음	❌ 실행되지 않음
성능 최적화 적용 여부	❌ 없음	✅ 일부 최적화 (Repeatable Read, JDBC 최적화 가능)

@Transactional 이 없는 경우

public void findPlaceTwice(Long id) {
    Place place1 = placeRepository.findById(id).orElseThrow();
    Place place2 = placeRepository.findById(id).orElseThrow();
}

@Transactional이 없는 경우 영속성 컨텍스트가 생성되긴 하지만 바로 닫혀버린다. 즉, findById(id) 라는 조회용 메서드를 실행 후 영속성 컨텍스트는 바로 닫힌다.
예를들어, findById(id)를 호출하게 되면 Spring Data JPA가 내부적으로 임시 트랜잭션을 만들어서 조회 후 즉시 종료한다.
따라서 동일한 메서드 내에서 동일한 엔티티를 여러번 조회하면, 계속 DB에서 조회를 하게된다. (1차 캐시 없음)
트랜잭션이 없으므로 데이터 일관성이 보장되지 않는다.

@Transactoinal(readOnly=true) 인 경우

@Transactional(readOnly = true)
public void findPlace(Long id) {
    Place place = placeRepository.findById(id).orElseThrow();
}

readOnly=true를 사용하면, 트랜잭션을 유지하므로 영속성 컨텍스트도 유지된다.
하지만 변경감지와 flush는 비활성화
반복 읽기(Repeatable Read) 최적화가 가능
트랜잭션이 유지 되므로 동일한 엔티티를 여러번 조회하면 1차캐시에서 가져올 수 있음