트랜잭션이 성공하면 결과는 영구히 반영되어야 한다.
해당 트랜잭션에 의한 모든 변경은 향후에 어떤 소프트웨어나 하드웨어 장애가 발생되더라도 보존되어야 한다.
동시에 여러 트랜잭션이 DB에 접근할 때 접근을 어떻게 제어할 것인가?
각 트랜잭션에 알맞는 격리수준을 선택하는 것이 중요하다.
한 트랜잭션에서 사용하는 데이터를 다른 트랜잭션에서는 사용할 수 없다.
정합성 문제 없음.
현재 트랜잭션에서 다른 트랜잭션으로 이동할때, 트랜잭션 내부에서 또다른 트랜잭션을 호출할 때 어떻게 처리할 것 인가?
진행중인 트랜잭션 O | 진행중인 트랜잭션 X | |
---|---|---|
Required | 트랜잭션 생성 | 트랜잭션 생성 |
Mandatory | 트랜잭션 생성 | 예외발생 |
Required_new | 현재 트랜잭션 보류, 새로 생성 | 트랜잭션 생성 |
Supports | 현재 트랜잭션 사용 | 트랜잭션 생성안함 |
Not_Supported | 현재 트랜잭션 보류 | 트랜잭션 생성안함 |
Never | 예외발생 | 트랜잭션 생성안함 |
Nested | 중첩 트랜잭션 생성 | 트랜잭션 생성 |
tx.begin(), tx.commit()을 자동으로 수행해주고, 예외 발생시 rollback처리
/**
* tx는 transaction을 의미.
*/
public void saveAuctionInfo(Auction auction) {
try {
tx.begin();
auctionRepository.save(auction);
tx.commit();
} catch (Exception e) {
tx.rollback();
}
}
@Transactional
public void register(Auction auction) {
auctionRepository.save(auction);
}
@Transactional없는 코드의 단점
- it's repetitive and error prone(반복적이며 에러에 취약)
- any error can have a very high impact(모든 에러가 치명적)
- errors are hard to debug and reproduce(디버깅하기 어려움)
- this decreases the readability of the code base(코드가독성 저하)
@Transactional을 통해 얻을 수 있는 것.
- transaction propagation are handled automatically.(자동적으로 트랜잭션 전파가 다루어짐)
- 상기의 단점들을 보완.