틀린 해석이 있다면 알려주세요
Transaction
Transaction : 데이터베이스 상태를 변화시키기 위해 수행하는 작업 단위를 말한다
쉽게 말해 sql 문으로 db 에 액세스하여 데이터베이스를 변경하는 것이다.
트랜잭션의 특징은
atomicity 원자성 : 모두 반영 또는 아예 안반영
consistency 일관성 : 작업 처리 결과는 항상 일관성있어야함
Isolation 독립성 : 두개이상의 트랜잭션이 실행되더라도 각각의 트랜잭션으로만 유지되는 것이지 서로 섞일 수 없다
(트랜잭션A, B가 실행됐을때 A가 실행 중에 B의 결과를 확인할 수 없다)
Durability 지속성 : 반영되어 성공됐을 경우, 이 결과는 영구적임
근데 이건 스프링이 다 관리해주겠다는 것임
스프링 프레임워크는 이런 트랜잭션 관리를 위해 일관적인 추상화를 제공한다고 설명되어있다
- A consistent programming model across different transaction APIs, such as Java Transaction API (JTA), JDBC, Hibernate, and the Java Persistence API (JPA).
- Support for declarative transaction management.
- A simpler API for programmatic transaction management than complex transaction APIs, such as JTA.
- Excellent integration with Spring’s data access abstractions.
1.1. Advantages of the Spring Framework’s Transaction Support Model
전통적인 EE application 는 트랜잭션 관리를 위해 global or local transactions 를 선택하여 사용했는데, 둘다 심각한 제한 점이 있다고 한다
그래서 스프링프레임워크는 이 제한 사항을 해결했다고 한다
1.1.1. Global Transactions
전역 트랜잭션을 사용하면 일반적으로 relational databases and message queues 와 같은 여러 트랜잭션 리소스로 작업이 가능하다.
애플리케이션 서버는 JTA 를 통해 글로벌 트랜잭션을 관리하는데, JTA UserTransaction normally needs to be sourced from JNDI .
JTA를 사용하려면 JNDI도 사용해야한다고 한다.
그래서 이 JTA는 일반적으로 애플리케이션 서버 환경에서만 사용할 수 있어 전역 트랜잭션으로 사용하려면 애플리케이션 코드의 잠재적 재사용이 제한된다
이전에는 EJB CMT(Container Managed Transaction - 선언적 트랜잭션 관리 형태)를 통해 글로벌 트랜잭션을 사용했고
이는 트랜잭션 관련 JNDI 조회 필요성은 제거해주지만 결국 EJB 자체를 사용하려면 JNDI를 사용해야한다고 한다
JNDI?
JNDI(Java Naming and Directory Interface)는 디렉터리 서비스에서 제공하는 데이터 및 객체를 발견(discover)하고 참고(lookup)하기 위한 자바 API다. - 위키백과
https://ko.wikipedia.org/wiki/JNDI
JNDI - 위키백과, 우리 모두의 백과사전
위키백과, 우리 모두의 백과사전. -->
ko.wikipedia.org
어쨌든 이러나 저러나 JDNI를 또 사용해야하고, 서버환경에 묶여있는 등의 단점이 크다고 한다
(공부할게 더 늘었군ㅡㅜ)
1.1.2. Local Transactions
Local Transaction은 JDBC연결과 관련된 트랜잭션과 같이 리소스별로 다르다.
사용하기 쉬울 수는 있으나, 여러 트랜잭션 리소스에서 작동할 수가 없다.
JDBC 트랜잭션을 관리하는 코드는 전역 JTA 트랜잭션 내에서 실행할 수 없다.
응용 프로그램 서버는 트랜잭션 관리에 관여하지 않기 때문에 여러 리소스에서 정확성을 보장할 수 없다.
(대부분의 애플리케이션이 단일 리소스를 사용하긴 하지만)
또 다른 단점은 로컬 트랜잭션이 프로그래밍 모델을 침법한다는 것이다
1.1.3. Spring Framework’s Consistent Programming Model
스프링은 위의 두 트랜잭션의 단점을 해결할 수 있다.
일단 애플리케이션 개발자는 모든 환경에서 일관된 프로그래밍 모델 사용이 가능하다
코드를 한 번만 작성해도 알아서 다양한 환경에서 관리전략을 활용할 수 있고,
선언적 트랜잭션 관리와 프로그램적 트랜잭션 관리를 모두 제공하고 있다
대부분의 사용자는 선언적 트랜잭션 관리를 선호한다.
프로그래밍 방식의 트랜잭션 관리는 스프링 프레임워크의 추상화 트랜잭션으로 작업하는데
선호하는 선언적 모델을 사용하고, 일반적으로 트랜잭션 관련된 코드를 거의 ~ 전혀 작성하지 않으므로
트랜잭션 API, 기타 트랜잭션 API 에 의존하지않을 수 있다.
The Spring Framework gives you the choice of when to scale your application to a fully loaded application server. Gone are the days when the only alternative to using EJB CMT or JTA was to write code with local transactions (such as those on JDBC connections) and face a hefty rework if you need that code to run within global, container-managed transactions. With the Spring Framework, only some of the bean definitions in your configuration file need to change (rather than your code).
기존 엔터프라이즈 자바 어플리케이션에 별도 어플리케이션 서버가 필요한 순간이지만, 트랜잭션을 스프링 프레임워크로 관리하면 이야기가 달라진다.
설명을 간단히 하자면 우리는 트랜잭션 관리에 너무 많은 힘을 주고 작업하지않아도 된다는 뜻으로 해석된다
필요할 때 어플리케이션을 확장하여
로컬 트랜잭션(JDBC 커넥션 기반)으로 작업한 코드에 일부 설정만 바꿔주면 간단히 해결된다.
'Web > spring' 카테고리의 다른 글
[Spring framework Web MVC docs] 1.8. Error Responses (0) | 2023.02.04 |
---|---|
[Spring framework Core] 1.3. Bean Overview (0) | 2023.02.03 |
[Spring framework Web MVC docs] 1.3.7 ControllerAdvice (0) | 2023.02.02 |
[Spring framework Web MVC docs] 1.3.5 DataBinder ~ 1.3.6 Exception (0) | 2023.02.02 |
[Spring framework Web MVC docs] 1.3.4 Model (0) | 2023.02.02 |