@Transactional

 

트랜잭션이란?

데이터베이스의 상태를 변경시키는 작업 또는 한번에 수행되어야하는 연산들을 말한다. 트랜잭션 작업이 끝나면 commit 또는 rollback 되어야한다.

 

트랜잭션 성질

• 원자성(Atomicity) : 한 트랜잭션 내에서 실행한 작업들은 하나의 단위로 처리한다. 즉 모두 성공 또는 모두 실패이다.
• 일관성(Consistency) : 트랜잭션은 일관성 있는 데이터베이스 상태를 유지한다.
• 격리성(Isolation) : 동시에 실행되는 트랜잭션들이 서로 영향을 미치지 않도록 격리해야한다.
• 지속성(Durability) : 트랜잭션이 성공적으로 처리되면 결과가 항상 저장되어야 한다.

---

@Transactional

• 스프링에서는 @Transactional 어노테이션을 선언하는 방법으로 트랜잭션 처리를 지원하는데, 이를 선언적 트랜잭션이라 한다. 클래스나 메서드 위에 @Transactional 이 추가되면, 이 클래스에 트랜잭션 기능이 적용된 프록시 객체가 생성된다. 이 프록시 객체는 @Transactional이 포함된 메소드가 호출 될 경우, PlatformTransactionManager를 사용하여 트랜잭션을 시작하고, 정상 여부에 따라 Commit 또는 Rollback 한다.
• 트랜잭션의 적용 우선 순위는 클래스의 메소드 > 클래스 > 인터페이스의 메소드 > 인터페이스 순이다.
• 스프링부트에서는 별도의 설정없이 사용할 수 있다.

 

@Transactional(readOnly=...,
                     isolation=...,
                     propagation=...,
                     timeout=...,
                     rollbackFor=..., rollbackForClassName=...,
                     noRollbackFor=..., noRollbackForClassName=...)

 

* PlatformTrasactionManager : 스프링 트랜잭션 처리의 중심이 되는 인터페이스로, 스프링 프레임워크는 다양한 환경과 제품에 대응하는 PlatformTransactionManager의 구현 클래스를 제공한다.

 - DataSourceTransactionManager : JDBC 및 마이바티스 등의 JDBC 기반 라이브러리로 데이터베이스에 접근하는 경우에 이용한다.

 - HibernateTransactionManager : 하이버네이트를 이용해 데이터베이스에 접근하는 경우에 이용한다.

 - JpaTransactionManager : JPA로 데이터베이스에 접근하는 경우에 이용한다.

[PlatformTransactionManager 설명 : springsource.tistory.com/127]

[Spring 3 - Transaction] 트랜잭션 추상화 클래스의 종류와 사용법

 

@Transactional 옵션

 

1. propagation(@Transactional(propagation=Propagation.REQUIRED)) : 트랜잭션 동작 도중 다른 트랜잭션을 호출할 때, 어떻게 할 것인지 지정하는 옵션이다.

• REQUIRED(Default) : 이미 진행중인 트랜잭션이 있다면 해당 트랜잭션 속성을 따르고, 진행중이 아니라면 새로운 트랜잭셕을 생성한다.
• REQUIRES_NEW : 항상 새로운 트랜잭션을 생성한다. 이미 진행중인 트래잭션이 있다면 잠깐 보류하고 해당 트랜잭션 작업을 먼저 진행한다.
• SUPPORT : 이미 진행중인 트랜잭션이 있다면 해당 트랜잭션 속성을 따르고, 없다면 트랜잭션을 설정하지 않는다.
• NOT_SUPPORT : 이미 진행중인 트랜잭션이 있다면 보류하고, 트랜잭션 없이 작업을 수행한다.
• MANDATORY : 이미 진행중인 트랜잭션이 있어야만 작업을 수행한다. 없다면 Exception을 발생시킨다.
• NEVER : 트랜잭션이 진행중이지 않을 때 작업을 수행한다. 트랜잭션이 있다면 Exception을 발생시킨다.
• NESTED : 진행중인 트랜잭션이 있다면 중첩된 트랜잭션이 실행되며, 존재하지 않으면 REQUIRED와 동일하게 실행된다.

 

2. isolation(@Transactional(isolation=Isolation.DEFAULT)) : 트랜잭션에서 일관성없는 데이터 허용 수준을 설정한다.

• Default : 사용하는 DB 드라이버의 디폴트 설정을 따른다. 대부분 READ_COMMITED를 기본 격리수준으로 설정한다.
• READ_UNCOMMITED : 가장 낮은 격리 수준이다. 트랜잭션이 커밋되기 전에 그 변화가 다른 트랜잭션에 그대로 노출된다. 예를들어, 트랜잭션A가 어떤 값을 x에서 y로 변경하고 아직 커밋하지 않은 상황에서 트랜잭션B가 해당 값을 읽을 경우 트랜잭션B에 y가 조회되는 것이다. 하지만 속도가 빠르기 때문에 데이터의 일관성이 떨어지더라도, 성능 극대화를 위해 의도적으로 사용하기도 한다. 
• READ_COMMITED : 트랜잭션이 커밋하지 않은 정보는 읽을 수 없다. 하지만 트랜잭션이 읽은 로우를 다른 트랜잭션에서 수정할 수 있다. 그래서 트랜잭션이 같은 로우를 읽었어도 시간에 따라서 다른 내용이 발견될 수 있다. 예를들어 트랜잭션A가 수정중인 어떤 값에 대해서 트랜잭션B는 읽을 수 없다. 반대로 트랜잭션B가 어떤 값을 두 번 조회하는 과정 중 첫번째 조회가 끝나고 두번째 조회가 이루어지는 사이에 트랜잭션A가 해당값을 수정하면 트랜잭션B는 두번째 조회에서 수정된 값을 조회하게 된다.
• REPEATABLE_READ : 트랜잭션이 읽은 로우를 다른 트랜잭션에서 수정되는 것을 막아준다. 예를 들어 트랜잭션A가 어떤 값을 두번 조회할 때 그 과정에서 중간에 트랜잭션B가 해당값을 수정하려하지만, 이미 트랜잭션A가 읽은 로우이기 때문에 수정이 이루어지지 않아서 트랜잭션A는 두번 모두 일정한 값을 조회할 수 있다. 하지만 새로운 로우를 추가하는 것은 제한하지 않는다.
• SERIALIZABLE : 가장 강력한 트랜잭션 격리수준이다. 여러 트랜잭션이 동시에 같은 테이블 로우에 엑세스하지 못하게 한다. 가장 안전하지만 가장 성능이 떨어진다. 예를들어 트랜잭션 A가 어떤 값을 조회하는 동안 모든 데이터에 대해 shared lock이 걸려 트랜잭션B는 그 영역에 해당되는 데이터에 대한 추가 및 수정이 불가능하다.

 

3. noRollbackFor(@Transactional(noRollbackFor=Exception.class))

• 특정 예외 발생 시 rollback하지 않는다.
• rollbackFor 속성과는 반대로 런타임 예외가 발생해도 지정한 런타임 예외면 커밋을 진행한다.

 

4. rollbackFor(@Transactional(rollbackFor=Exception.class))

• 특정 예외 발생 시 rollback한다.

 * 트랜잭션 작업 중 런타임 예외가 발생하면 롤백한다. 반면에 예외가 발생하지 않거나 체크 예외가 발생하면 커밋한다. 체크 예외를 커밋 대상으로 삼는 이유는 체크 예외가 예외적인 상황에서 사용되기 보다는 리턴 값을 대신해서 비즈니스 적인 의미를 담은 결과로 돌려주는 용도로 사용되기 때문이다. 스프링에서는 데이터 엑세스 기술의 예외를 런타임 예외로 전환해서 던지므로 런타임 예외만 롤백대상으로 삼는다. 하지만 rollbackFor또는 rollbackForClassName 속성을 이용해서 예외를 지정해서 체크예외지만 롤백 대상으로 삼을 수 있다.

 

5. timeout(@Transactional(timeout=10))

• 트랜잭션에 제한시간을 지정한다.
• 초 단위로 지정하고, 디폴트 설정으로 트랜잭션 시스템의 제한시간을 따른다. 지정한 시간 내에 수행이 완료되지 않으면 rollback한다.
• -1 입력 시, 트랜잭션 제한시간을 사용하지 않는다.

 

6. readOnly(@Transactional(readOnly = true)) 

• 트랜잭션을 읽기 전용으로 설정한다. 특정 트랜잭션 안에서 쓰기 작업이 일어나는 것을 의도적으로 방지하기 위해 사용된다.
• Default값은 false이다.
• INSERT, UPDATE, DELETE 작업이 진행되면 예외가 발생한다.

 

bamdule.tistory.com/51