Loading...
Spring Framework Reference Documentation 7.0.2의 Advantages of the Spring Framework’s Transaction Support Model의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
전통적으로, EE 애플리케이션 개발자는 트랜잭션 관리를 위해 두 가지 선택지를 가져왔습니다: global 또는 local 트랜잭션으로, 둘 다 심각한 한계를 가지고 있습니다. Global 및 local 트랜잭션 관리는 다음 두 섹션에서 검토되며, 그 다음에 Spring Framework의 트랜잭션 관리 지원이 global 및 local 트랜잭션 모델의 한계를 어떻게 해결하는지에 대한 논의가 이어집니다.
Global 트랜잭션은 일반적으로 관계형 데이터베이스와 메시지 큐와 같은 여러 트랜잭션 리소스를
다룰 수 있게 해줍니다. 애플리케이션 서버는 JTA를 통해 global 트랜잭션을 관리하는데,
JTA는 (부분적으로는 그 예외 모델 때문에) 다루기 힘든 API입니다. 또한, JTA UserTransaction은
일반적으로 JNDI에서 가져와야 하므로, JTA를 사용하기 위해서는 JNDI도 사용해야 합니다.
Global 트랜잭션을 사용하면 애플리케이션 코드의 잠재적인 재사용성이 제한되는데, JTA는 일반적으로 애플리케이션 서버 환경에서만 사용 가능하기 때문입니다.
이전에, global 트랜잭션을 사용하는 선호되는 방식은 EJB CMT (Container Managed Transaction)를 사용하는 것이었습니다. CMT는 선언적 트랜잭션 관리의 한 형태입니다 (프로그래매틱 트랜잭션 관리와 구별됩니다). EJB CMT는 트랜잭션 관련 JNDI 조회의 필요성을 제거하지만, EJB 자체를 사용하면 JNDI 사용이 필수적입니다. 이는 트랜잭션을 제어하기 위한 Java 코드 작성의 대부분(그러나 전부는 아님)의 필요성을 제거합니다.
중요한 단점은 CMT가 JTA 및 애플리케이션 서버 환경에 묶여 있다는 점입니다. 또한, 비즈니스 로직을 EJB(또는 적어도 트랜잭션 EJB 파사드 뒤에서)로 구현하기로 선택한 경우에만 사용할 수 있습니다. 일반적으로 EJB의 부정적인 점이 너무 크기 때문에, 특히 선언적 트랜잭션 관리에 대한 설득력 있는 대안이 존재하는 상황에서는 이것이 매력적인 제안이 아닙니다.
Local 트랜잭션은 JDBC 커넥션에 연결된 트랜잭션과 같이 리소스 특화적입니다. Local 트랜잭션은 사용하기 더 쉬울 수 있지만 중요한 단점이 있습니다: 여러 트랜잭션 리소스에 걸쳐 동작할 수 없다는 점입니다. 예를 들어, JDBC 커넥션을 사용하여 트랜잭션을 관리하는 코드는 global JTA 트랜잭션 내에서 실행될 수 없습니다.
애플리케이션 서버가 트랜잭션 관리에 관여하지 않기 때문에, 여러 리소스에 걸친 정확성을 보장하는 데 도움을 줄 수 없습니다. (대부분의 애플리케이션이 단일 트랜잭션 리소스를 사용한다는 점은 주목할 가치가 있습니다.) 또 다른 단점은 local 트랜잭션이 프로그래밍 모델에 침투적(invasive)이라는 점입니다.
Spring은 global 및 local 트랜잭션의 단점을 해결합니다. 이는 애플리케이션 개발자가 어떤 환경에서든 일관된 프로그래밍 모델을 사용할 수 있게 해줍니다. 코드를 한 번만 작성하면, 서로 다른 환경에서 서로 다른 트랜잭션 관리 전략의 이점을 누릴 수 있습니다.
Spring Framework는 선언적 및 프로그래매틱 트랜잭션 관리를 모두 제공합니다. 대부분의 사용자는 선언적 트랜잭션 관리를 선호하며, 우리는 대부분의 경우 이를 권장합니다.
프로그래매틱 트랜잭션 관리에서는 개발자가 Spring Framework 트랜잭션 추상화를 사용하여 작업하며, 이는 어떤 기반 트랜잭션 인프라스트럭처 위에서도 동작할 수 있습니다. 선호되는 선언적 모델에서는 개발자가 일반적으로 트랜잭션 관리와 관련된 코드를 거의 또는 전혀 작성하지 않으며, 따라서 Spring Framework 트랜잭션 API나 다른 어떤 트랜잭션 API에도 의존하지 않습니다.
Spring Framework의 트랜잭션 관리 지원은 엔터프라이즈 Java 애플리케이션이 언제 애플리케이션 서버를 필요로 하는지에 대한 전통적인 규칙을 변화시킵니다.
특히, EJB를 통한 선언적 트랜잭션만을 위해 애플리케이션 서버가 필요하지는 않습니다. 실제로, 애플리케이션 서버가 강력한 JTA 기능을 가지고 있더라도, Spring Framework의 선언적 트랜잭션이 EJB CMT보다 더 강력한 기능과 더 생산적인 프로그래밍 모델을 제공한다고 판단할 수 있습니다.
일반적으로, 애플리케이션이 여러 리소스에 걸친 트랜잭션을 처리해야 하는 경우에만 애플리케이션 서버의 JTA 기능이 필요하며, 이는 많은 애플리케이션에서 요구되지 않습니다. 많은 하이엔드 애플리케이션은 그 대신 단일의, 매우 확장 가능한 데이터베이스(예: Oracle RAC)를 사용합니다.
독립 실행형 트랜잭션 매니저(예: Atomikos Transactions) 와 같은 다른 선택지도 있습니다. 물론, Java Message Service (JMS) 및 Jakarta EE Connector Architecture (JCA)와 같은 다른 애플리케이션 서버 기능이 필요할 수 있습니다.
Spring Framework는 애플리케이션을 완전히 기능이 갖춰진 애플리케이션 서버로 언제 스케일할지에 대한 선택권을 제공합니다. EJB CMT 또는 JTA를 사용하는 것에 대한 유일한 대안이 local 트랜잭션(JDBC 커넥션 상의 트랜잭션과 같은)을 사용하여 코드를 작성하고, 해당 코드를 global, 컨테이너 관리 트랜잭션 내에서 실행해야 할 경우 대규모 재작업을 감수해야 했던 시대는 지났습니다.
Spring Framework에서는 설정 파일의 빈 정의 일부만 (코드가 아니라) 변경하면 됩니다.
Transaction Management
Understanding the Spring Framework Transaction Abstraction