@Transactional이란?
모든 작업들이 성공적으로 완료되어야 작업 묶음의 결과를 적용하고, 어떤 작업에서 오류가 발생했을 때는 이전에 있던 모든 작업들이 성공적이었더라도 없었던 일처럼 완전히 되돌리는 것이 트랜잭션의 개념입니다.
데이터베이스를 다룰 때 트랜잭션을 적용하면 데이터 추가, 갱신, 삭제 등으로 이루어진 작업을 처리하던 중 오류가 발생했을 때 모든 작업들을 원상태로 되돌릴 수 있습니다. 모든 작업들이 성공해야만 최종적으로 데이터베이스에 반영하도록 합니다.
트랜잭션의 특징
트랜잭션의 특징은 크게 4가지로 구분된다.
- 원자성 (Atomicity)
- 일관성 (Consistency)
- 독립성 (Isolation)
- 지속성 (Durability)
첫번째로, 원자성은 트랜잭션이 데이터베이스에 모두 반영되던가, 아니면 전혀 반영되지 않아야 한다는 것이다. 트랜잭션은 사람이 설계한
논리적인 작업 단위로서, 일처리는 작업단위 별로 이루어 져야 사람이 다루는데 무리가 없다.
만약 트랜잭션 단위로 데이터가 처리되지 않는다면, 설계한 사람은 데이터 처리 시스템을 이해하기 힘들 뿐만 아니라, 오작동 했을시 원인을 찾기가 매우 힘들어질것이다.
두번째로, 일관성은 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 한다는 것이다.
트랜잭션이 진행되는 동안에 데이터베이스가 변경 되더라도 업데이트된 데이터베이스로 트랜잭션이 진행되는것이 아니라,
처음에 트랜잭션을 진행 하기 위해 참조한 데이터베이스로 진행된다. 이렇게 함으로써 각 사용자는 일관성 있는 데이터를 볼 수 있는 것이다.
세번째로, 독립성은 둘 이상의 트랜잭션이 동시에 실행되고 있을 경우 어떤 하나의 트랜잭션이라도, 다른 트랜잭션의 연산에 끼어들 수 없다는 점을 가리킨다.
하나의 특정 트랜잭션이 완료될때까지, 다른 트랜잭션이 특정 트랜잭션의 결과를 참조할 수 없다.
네번째로, 지속성은 트랜잭션이 성공적으로 완료됬을 경우, 결과는 영구적으로 반영되어야 한다는 점이다.
@Transactional(readOnly = true)
@Transactional 작업을 처리하기 위해 많은 리소스가 사용됩니다.
특히 CUD sql문에서는 이전 상태로 돌려야하기 때문에, 이전 상태를 가지고 있어야합니다.
하지만 select문 같은 경우는 쿼리를 실행해도 이전 상태와 변화가 없으므로 해당 transaction에 lock을 적용할 필요가 없습니다.
그렇기때문에 (readOnly = true) 옵션을 사용하여 해당 메서드가 읽기 전용이라는 것을 명시하고, 영속성 컨텍스트에 관리를 받지않게 됩니다.
또한 변경감지 수행등을 하지 않아 @Transactional의 격리 수준보다 낮은 수준의 격리 수준을 사용하게 됩니다.
여기까지 알고 난 후, 의문이 하나 들었습니다.
그렇다면 JPA를 쓰지 않는다면 굳이 왜 @Transactional(readOnly = true)를 사용할까? 그냥 transaction 어노테이션을 사용하지 않아도 되지 않나?
그래서 @Transactional(readOnly = true) 사용했을 때의 장단점을 살펴보려고 합니다.
장점
- readOnly라고 명시하므로 읽는 개발자가 읽기 전용 메서드라는 것을 알 수 있습니다.
- JPA를 사용할 경우, 변경감지 작업을 수행하지 않아 성능상의 이점이 있습니다.
- 트랜잭션 ID 설정에 대한 오버헤드를 해결하고, 스냅샷을 통해 데이터의 일관성을 보장한다.
- CRUD를 하는 service에서 클래스에 @Transactional을 붙여 중복을 줄이고 싶을 때 read 메서드에 사용하여 격리 수준을 바꿔줄 수 있다.
단점
- 사용하지 않았을 때보다 자원(프록시)을 사용하므로 느리다.
좁은 견해로 장단점은 이정도로 정리할 수 있을 것 같습니다.
JPA를 쓰지 않을 때는 사실 성능상으로 큰 이점이 없어보여서 (read 명시 + 클래스에 어노테이션을 붙였을 때 read 메서드 처리가능) VS 프록시 사용 중에서 해당 프로젝트의 장단점을 따져서 사용하면 될 것 같습니다.
출처: https://mommoo.tistory.com/62 [개발자로 홀로 서기:티스토리]