트랜젝션 레벨 조정할때마다 자꾸 찾아보게 되서 정리 .. 추가로 readOnly 속성은 이번에 처음알았음 ㅇㅅㅇ,,
(JPA를 사용할 경우 특히나 중요함.)
Propagation
- 전파 레벨 속성으로 부모 자식(?) 트랜잭션간의 영향 수준을 정의하는 옵션
- 새로운 커넥션에 트랜잭션을 적용할지 기존 커넥션에 포함되어 트랜잭션이 적용될지 ..?
// 전파 레벨 적용 예시 (REQUIRED는 디폴트값이므로 생략가능 = @Transactional만 선언한것과 같다.)
@Transactional(propagation=Propagation.REQUIRED)
public void transactionTest(){
//
}
1. REQUIRED (default)
- 부모 트랜잭션이 있는 경우 부모 트랜잭션 내에서 동작하며, 없는 경우엔 새로운 연결을 생성한다.
- 호출된 자식 트랜잭션에서 예외가 발생한 경우 호출한 부모 트랜잭션도 함께 rollback된다.
- 예외가 발생할 경우 부모에게 전파됨.
2. REQUIREDS_NEW
- 부모 트랜잭션이 있을 경우 잠시 대기 시키고 새로운 트랜잭션을 생성함.
- 해당 메서드를 실행할 때 마다 새로운 트랜잭션 내에서 동작하며, 예외가 발생해도 부모에게 전파되지 않음.
3. NESTED
- 부모 트랜잭션이 있는 경우 savepoint를 지정 가능하여 지정된 곳 까지만 rollback가능하다. (DB에서 지원하는 경우)
- 부모 트랜잭션이 없을 경우 REQUIRED 속성과 동일게 동작한다.
4. SUPPORT
- 부모 트랜잭션이 있을 경우 부모 트랜잭션 내에 속하여 동작함.
- 부모가 없으면 @transactional이 없는것과 동일.(non_transactional)
5. NOT_SUPPORT
- non_transactional하게 동작하며, 부모 트랜잭션이 존재하면 잠시 대기한다.
6. MANDATORY
- 부모 트랜잭션 내에서만 동작하며 부모가 없을경우 예외가 발생한다.
7. NEVER
- non_transactional하게 동작하며, 부모가 있으면 예외가 발생.
Isolation
- 트랜잭션간의 격리 수준을 지정하는 옵션
@Transactional(isolation=Isolation.READ_COMMITTED)
public void transactionTest(){
//
}
1. READ_UNCOMMITTED (정합성 문제로 권장하지 않음)
- rollback이나 commit 여부에 상관없이 다른 트랜잭션 작업이 완료되지 않아도 값을 읽는것을 허용.
2. READ_COMMITTED (대부분의 RDBMS의 default속성)
- commit된 값만을 읽지만 한 트랜잭션 내에서
3. REPEATABLE_READ
- 트랜잭션 수행 도중 다른 트랜잭션에서 commit된 데이터가 있어도 첫 select시 생성된 스냅샷내에서 데이터를 읽어옴.
+) consistent read : 데이터 조회 시 현 시점의 데이터가아닌 특정 시점의 DB스냅샷을 읽어오는 것.
4. SERIALIZABLE (dead lock 걸릴 가능성이 있기때문에 신중하게 사용해야함)
- 가장 엄격한 격리수준으로 select 쿼리가 selet~for share로 자동으로 변경되며 lock을 통해 phantom read현상을 방지함.
+) phantom read : update & commit 후 select 시 예상과는 다른값이 보이거나 데이터가 유실된 경우.
rollbackFor
- 특정 예외 발생 시 rollback되도록 하는 옵션
// IOException 발생 시 rollback 되도록 정의
@Transactional(rollbackFor={IOException.class})
public void transactionTest(){
//
}
readOnly
- @Transactional로 선언한것 보다 낮고 non-transactional 보다는 높은 격리수준이라 할 수 있다.
- JPA를 사용한다면 변경감지 등을 수행하지 않아 성능을 향상 시킬 수 있다.
@Transactional(readOnly=true)
public void transactionalTest(){
//
}
https://resilient-923.tistory.com/391
[Spring / TIL] @Transactional(readOnly=true) 가 꼭 필요한가?
Spring 학습을 위해 프로젝트를 진행하던 도중 조회한 값을 return 해주는 메소드에 당연하게 @Transactional(readOnly=true) 어노테이션을 사용했습니다. 막연하게 롤백(rollback) 때 사용하니까 @Transactional
resilient-923.tistory.com
https://techblog.woowahan.com/2606/
응? 이게 왜 롤백되는거지? | 우아한형제들 기술블로그
{{item.name}} 이 글은 얼마 전 에러로그 하나에 대한 호기심과 의문으로 시작해서 스프링의 트랜잭션 내에서 예외가 어떻게 처리되는지를 이해하기 위해 삽질을 해본 경험을 토대로 쓰여졌습니다.
techblog.woowahan.com
https://nesoy.github.io/articles/2019-05/Database-Transaction-isolation
트랜잭션의 격리 수준(isolation Level)이란?
nesoy.github.io
'Java' 카테고리의 다른 글
[java] JSONTokener & JSONParser (0) | 2023.06.21 |
---|---|
[Java1.7] httpClient를 통한 api통신 (0) | 2023.06.21 |
[Java] 객체지향 설계 원칙 SOLID (0) | 2023.03.13 |
[Java] 클라이언트 IP 확인 (0) | 2023.03.09 |
[Java] Arrays.ArrayList (0) | 2023.03.09 |