보통 엔티티 수정, 삽입, 삭제는 없고 only 조회기능만 있는 비즈니스 로직에 대해서 메서드에 @Transactional(readonly = "true") 어노테이션을 붙이잖아.
그런데 DB 변경 가능성이 없는 기능에 대해서 굳이 트랜잭션을 걸어서 조회할 필요 있어? 걸었을 때 안걸었을 때 차이점이 뭐야?
보통 엔티티 수정, 삽입, 삭제는 없고 only 조회기능만 있는 비즈니스 로직에 대해서 메서드에 @Transactional(readonly = "true") 어노테이션을 붙이잖아.
그런데 DB 변경 가능성이 없는 기능에 대해서 굳이 트랜잭션을 걸어서 조회할 필요 있어? 걸었을 때 안걸었을 때 차이점이 뭐야?
이거 나도 궁금하네
뭔가 한 메서드 안에 여러 개의 조회 로직이 있을 때, 각 로직 당 하나의 커넥션이 사용되는게 아닐까용? 성능면에서...
이건 구글링해도 알수있다
SimpleJpaRepository 코드가 JpaRepository 구현체인데 이미 저기에 트랜잭션 어노테이션이 클래스랑 메서드에 붙어있음. 그래서 기본 트랜잭션 범위는 Repository임. 우리가 트랜잭션을 설정하냐마냐는 어차피 트랜잭션이 걸리기 때문에 의미가 없음
그러면 서비스 메서드에 여러개를 조회해야하는 상황이라면 서비스 단에 트랜잭션 사용 유무에 따라 하나의 트랜잭션으로 묶을 수 있냐 없냐가 달라짐 하나의 트랜잭션으로 묶는다 = 하나의 커넥션을 사용한다, 묶지않는다 = 여러 개의 커넥션을 사용한다
내가 저번에 트랜잭션 코드 하나하나 찾아보니까 트랜잭션이 실행될때마다 (커넥션을 새로 얻고 -> ThreadLocal에 할당하고 -> 트랜잭션 연산 끝났으면 release하고)를 반복하는 걸로 기억함
서비스 메서드에서 Repository 트랜잭션에 걸리기 때문에 의미가 없다고 했잖아 여기서 궁굼한게 이때 서비스 메서드에서 트랜잭션 전파를 NOT_SUPPORTED로 선언하고 조회하면 트랜잭션 없이 조회되는거 아님?
?! 그렇게 해서 트랜잭션 없이 조회하는 방법도 있긴하네 그런건 생각도 안해봄
그거 명시적 선언으로 알고있는데 실제로는 트랜잭션 사용 안할껄 내부적으로 그리고 트랜잭션을 엮으나 안엮으나 쿼리가 여러개면 커넥션만 하나인거지 실제 쿼리는 여러번 날아감 - dc App
https://dev.mysql.com/doc/refman/8.4/en/set-transaction.html
트랜잭션
사용함
걍 트랜잭션 종류기 기본값(READ/WRITE), 읽기 전용(READ)로 나뉨
트랜잭션 격리 레벨에 따라 다르겠지만.. repeatable read가 가능한 격리 수준일 때, 다른 트랜잭션의 영향을 받지 않기 위해서 사용합니다. 조회 트랜잭션 중에 다른 트랜잭션에 의해서 row가 변경되어도 현재 조회는 별개의 트랜잭션이기 때문에 반복된 읽기가 가능한거죠.