[Spring] Transactional

웹 서비스를 개발하다보면 하나의 업무 로직에서 반드시 함께 처리 되어야하는 업무 단위가 있다. 예를 들어 송금의 상황에서 A가 B에게 송금을 했다면, A의 통장은 잔고가 업데이트 되어야 하고, B의 통장 잔고 또한 업데이트 되어야 하는데, 예기치 못한 상황이 발생해 A에서 돈이 빠져나갔지만, B에게 돈이 들어오지 않았다면... A에서 빠져나간 돈은 다시 원래대로 복구되어야 할 것이다. 이를 트랜잭션 처리라고 한다.

 

출처 : https://jerryjerryjerry.tistory.com/48

@Transactional

스프링의 트랜잭션은 AOP를 기반으로 동작한다. 즉 메인 로직의 시작과 끝에 붙어 트랜잭션을 처리해주는 것이다.

 

사실 개발자 입장에서는 @Transactional 어노테이션만 붙여주면 끝이난다. 하지만 이 어노테이션의 옵션을 한번 들여다보자.

전파 옵션 - Propagation

A라는 Service에서 B1, B2라는 Repository의 메서드를 이용한다고 할 때, 트랜잭션 처리를 해야한다. B1, B2의 로직이 함께 성공적으로 처리가 되어야 하기 때문이다. 그러면 A의 서비스 메서드 레이어에 @Transactional을 붙여주면, 밑의 Repository 메서드 까지 트랜잭션이 전파되는데, 그것이 싫다면 전파 옵션을 설정해 처리할 수 있다.

 

• Mandatory - 현재 트랜잭션을 지원하되, 트랜잭션이 존재하지 않으면 예외를 발생시킨다.
• Nested - 현재 트랜잭션이 존재하면, 나만의 트랜잭션을 중첩해서 트랜잭션을 실행하게 된다.
• Never - 트랜잭션이 걸린다면, 예외를 발생시킨다.
• Not_supported - 만일 외부 레이어의 트랜잭션이 있었다면, 나는 그 트랜잭션을 실행하지 않겠다. 심지어 내부에도 트랜잭션을 실행하지 않겠다.
• Required (Default) - 외부 레이어의 트랜잭션이 없다면, 내가 생성하도록 한다. (기본값)
• Requires_new - 밖에서 트랜잭션이 들어와도, 그것과 상관없이 나의 트랜잭션을 생성한다. 즉, 외부 레이어와 독립적으로 트랜잭션을 처리한다. 하지만 결과는 동일하게 보여진다.
• Supports - 외부 레이어의 트랜잭션이 있다면 유지하고, 없다면 트랜잭션 처리를 하지 않는다.

고립도 옵션 - Isolation

 ※ Dirty Read? 

- Rollback하게 될지도 모르는 데이터를 읽어들이는 것. Insert를 하던 Update를 하던 남에게 보여지면 안된다. 아직 Commit이 안되었기 때문에. 그럼 더티리드를 왜 허용하는가? 그것은 '성능' 때문이다.

 ※ Phenomenon Read? 

- A 데이터를 조회했는데, 다른 누군가가 A 데이터를 수정/삭제 했다면, 내가 다시 A를 조회했을 때 다른 데이터가 보여지는 기현상을 만난다. 이를 Lock을 통해 막을 수 있다.

 ※ Phantom Read? 

- 

 

• Default - DBMS의 기본값에 맞춤
• Read_Commited - Commit한 것만 읽어들이게 함. (Dirty Read가 발생하지 않음) 그러나 다시 읽어들일 수 없는 데이터를 읽어들인다. (Phenomenon Read 발생)
• Read_Uncommited - 더티 리드를 허용하는 것.
• Serializable - 내가 작업하고 있는 과정에 있는 레코드, 테이블에 Lock을 건다. 화장실을 사용하는데 아무도 못들어오게 건물을 막는 것과 유사.
• Repeatable_Read - 내가 작업하고 있는 과정에 있는 데이터에 누군가 손을 대려고 하면 막는다. (Lock을 건다)

ReadOnly

Default는 false.

 

true로 설정 시 데이터 삽입/수정/삭제가 일어나도 DB에 적용되지 않는다.