일단 @Transactional(readonly=true)는 메서드나 클래스에 적용해서 해당 트랜잭션을 읽기 전용으로 설정하는 기능을 한다. 해당 트랜잭션 내에서는 데이터를 읽기만 하고 변경 작업을 수행하지 않을 것임을 명시적으로 나타내준다.
도움이 되냐는 질문이라 아무래도 성능이나 리소스 측면으로 보면, readonly로 설정을 하면 성능 향상이랑, 리소스를 최적화 할 수 있다는 장점이 있다.
해당 옵션인 경우 spring framework가 hibernate 세션 플러시 모드를 MANUAL로 설정한다. 이렇게 하면 강제로 플러시를 호출하지 않는 한 플러시가 일어나지 않는다. 따라서 트랜잭션을 커밋하더라도 영속성 컨텍스트가 플러시 되지 않아서 엔터티의 등록, 수정, 삭제가 동작하지 않고, 또한 읽기 전용으로, 영속성 컨텍스트는 변경 감지를 위한 스냅샷을 보관하지 않으므로 성능이 향상된다.
또한, DB가 master와 slave로 나누어져 있다면 ReadOnly가 있는 경우 읽기 전용으로 slave를 호출하게 된다. 즉, 상황에 따라 DB 서버의 부하를 줄일 수 있다.
(번외기는 하지만 replication을 구성했을 때, master db에서는 write(insert, update, delete)작업을 처리하고, slave db에서는 read(select)작업을 처리하게 해서 부하 분산을 시키는 것도 있고, 대부분 slave db는 보통 readOnly 설정을 해두는것이 일반적인데 이런것들과 관련이 있는 것 같다…)
리소스 최적화도 말했었는데, 보통 인덱스가 걸려있는 테이블의 write 작업은 read 작업보다 상대적으로 더 많은 시간이 걸리는데, 읽기 전용 트랜잭션은 쓰기 작업에 필요한 리소스를 사용하지 않기 때문에 더 많은 읽기 작업을 처리할 수 있다.
이러한 성능적인 관점 외에도, 읽기 전용 트랜잭션은 데이터를 변경하지 않기 때문에 데이터베이스에 락을 걸지않고 읽기 작업을 수행할 수 있고, 그렇기 때문에 다른 트랜잭션과의 충돌이나 대기 시간 없이 작업을 효율적으로 수행할 수 있다는 장점이 있다.
또한, readonly니까 데이터 변경이 없고, 그러면 다른 트랜잭션과 충돌로 인한 데이터 무결성 문제도 없을테고, 또 읽기 전용 트랜잭션은 일반적으로 낮은 격리 수준을 사용하는데, 격리 수준이 낮으면 락을 적게 사용하고 이게 또 성능 향상으로 이어지는… 이러한 장점들이 있을 수 있겠다.
해당 어노테이션만 있다면 우리는 해당 메서드는 READ에 대한 동작만 수행할 것이라고 예상하고 이루어진다. 여기서 난 객체지향으로 작업할 때 가능한 경우 final을 두어 객체의 신뢰성을 보장하는 것이 떠올랐다. 그리고 난 이 점이 중요하다고 느껴졌기에 해당 옵션에서 아무런 성능적 이점을 갖지 못한 경우라도 명시적으로 두는 것도 좋은 방법이라고 생각한다.
