[JPA] @Transactional(readOnly = true) 은 왜 사용해요?

@Transactional(readOnly = true) 은 왜 사용해요?

장단점을 확인해보면서 알아보자

장점

• readOnly = true 사용시, 하이버네이트 세션 플러시 모드를 MANUAL로 적용한다. 때문에 강제로 flush를호출해야만 flush가 일어난다. 때문에 엔티티의 변경되는 동작을 하지 않기 때문에 엔티티 변경에 안전하다. 또한 JPA는 해당 트랜잭션 내에서 조회하는 Entity는 읽기전용으로 인식하고, 변경 감지를 위한 Snapshot을 따로 보관하지 않으므로 메모리가 절약되는 성능상 이점,(그냥 @Transactional 만사용하면 @Transactional 사용 영역에서는 JPA의 스냅샷 유지, flush의 필요성, DB 커넥션을 오래 물고 있는 등의 관리적인 오버헤드 발생이라는 단점 존재)

• 나는 조회용 메서드에요! 라는 직관성 측면에서의 이점

• Master - Slave 구조의 DB 운영시, 데이터 read 작업은 오로지 slave 에서 진행하므로 Master와 Slave의 트래픽 분산이점
  

  public class RoutingDataSource extends AbstractRoutingDataSource {
      @Override
      protected Object determineCurrentLookupKey() { //readOnly 는 slave로 핸들링 가능 
          return (TransactionSynchronizationManager.isCurrentTransactionReadOnly()) ? "slave" : "master"; 
      }
  }

• read 쿼리시 db에 불필요한 Lock 을 걸지 않음(벤더마다 다름) (mysql 공식문서:https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-ro-txn.html)

 

 

단점

• 당연히 데이터 조회에 대한 로직만 들어가야겠지만 혹시나 데이터 변경에 관한 로직이 들어갈경우 의도치 않은 문제 발생, DB의 낙관적 락의 경우 동시에 두 트랜잭션(t1,t2)이 엔티티에 update를 할 때, 그 사이에 읽기 트랜잭션(t3)가 실행될 경우에 데이터 버전의 충돌감지가 안되기 때문에 정합성이 깨질수도 있다.