Loading...
Spring Framework Reference Documentation 7.0.2의 Declarative Transaction Management의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
대부분의 Spring Framework 사용자는 선언적 transaction management를 선택합니다. 이 옵션은 애플리케이션 code에 미치는 영향이 가장 적고, 따라서 비침투적인 lightweight 컨테이너라는 이상과 가장 일치합니다.
Spring Framework의 선언적 transaction management는 Spring aspect-oriented programming (AOP)을 통해 가능해집니다. 그러나 transactional aspects code는 Spring Framework 배포판에 포함되어 있으며 보일러플레이트 방식으로 사용할 수 있기 때문에, 이 code를 효과적으로 사용하는 데 AOP 개념을 반드시 이해할 필요는 없습니다.
Spring Framework의 선언적 transaction management는 EJB CMT와 유사하며, 개별 메서드 수준까지 transaction 동작(또는 그 부재)을 지정할 수 있습니다. 필요한 경우 transaction 컨텍스트 내에서 setRollbackOnly() 호출을 할 수 있습니다. 두 종류의 transaction management 간의 차이점은 다음과 같습니다:
setRollbackOnly()를 사용하는 것 외에는 컨테이너의 transaction management에 영향을 줄 수 없습니다.rollback rules 개념은 중요합니다. rollback rules는 어떤 exception (및 throwable)이 자동 rollback을 유발해야 하는지 지정할 수 있게 해줍니다. Java code가 아닌 설정에서 선언적으로 이를 지정할 수 있습니다.
따라서 여전히 TransactionStatus 객체에서 setRollbackOnly()를 호출하여 현재 transaction을 rollback할 수 있지만, 대부분의 경우 MyApplicationException이 항상 rollback을 초래해야 한다는 rule을 지정할 수 있습니다. 이 옵션의 중요한 이점은 비즈니스 객체가 transaction 인프라스트럭처에 의존하지 않는다는 점입니다. 예를 들어, 일반적으로 Spring transaction API나 다른 Spring API를 import할 필요가 없습니다.
EJB 컨테이너 기본 동작은 시스템 exception(일반적으로 런타임 exception)에서 transaction을 자동으로 rollback하지만, EJB CMT는 애플리케이션 exception(즉, java.rmi.RemoteException 이외의 체크드 exception)에 대해서는 transaction을 자동으로 rollback하지 않습니다.
Spring의 선언적 transaction management에 대한 기본 동작은 EJB 컨벤션(rollback은 언체크드 exception에서만 자동으로 수행됨)을 따르지만, 이 동작을 커스터마이즈하는 것이 유용한 경우가 많습니다.
Synchronizing Resources with Transactions
Understanding the Spring Framework’s Declarative Transaction Implementation