Spring @Transactional 작동 원리 상세 정보

본고는 Spring의 사무 관리를 깊이 연구할 것이다.주로 @Transactional이 밑에서 어떻게 일하는지 소개합니다.다음 글은 다음과 같습니다.
propagation(사무 전파)과 isolation(격리성) 등 속성 사용
사무에 사용되는 함정은 어떤 것들과 어떻게 피해야 하는가
JPA 및 트랜잭션 관리
중요한 점은 JPA 자체가 어떤 형식의 성명식 사무 관리도 제공하지 않는다는 것이다.만약 주입 용기에 의존하여 JPA를 사용한다면, 사무 처리는 반드시 개발자가 프로그래밍하여 실현해야 한다.

UserTransaction utx = entityManager.getTransaction();
try{
	utx.begin();
	businessLogic();
	utx.commit();
}
catch(Exception ex) {
	utx.rollback();
	throwex;
}

이러한 방식의 트랜잭션 관리는 코드에서 트랜잭션 범위를 명확하게 표현할 수 있지만 다음과 같은 단점이 있습니다.
중복 코드와 오류가 발생하기 쉽다
어떤 오류도 비교적 큰 영향을 미칠 수 있다
오류는 디버깅과 재현이 어렵다
코드 라이브러리의 가독성 감소
만약 이 방법이 다른 사무 방법을 호출한다면 어떻게 처리합니까?
Spring @Transactional 사용
Spring @Transactional을 사용하면 위의 코드가 다음과 같이 단순화됩니다.

@Transactional 
  publicvoid businessLogic() { 
    ... use entity manager inside a transaction ... 
  } 

코드가 더욱 간결하고 가독성이 좋으며 현재 스프링에서 사무 처리를 추천하는 방식이다.
@Transactional을 사용하면 업무 전파 등 여러 가지 중요한 부분을 자동으로 처리할 수 있습니다.이 경우 비즈니스 Logic () 에서 다른 트랜잭션 방법을 호출하면 이 방법은 옵션에 따라 실행 중인 트랜잭션에 가입하는 방법을 결정합니다.
이 강력한 메커니즘의 잠재적인 단점은 밑바닥의 운행을 숨기고 있으며, 정상적으로 작동하지 않을 때 디버깅하기 어렵다는 것이다.
@Transactional 의미
@Transactional과 관련하여 중요한 점 중 하나는 두 가지 독립된 개념을 고려해야 한다는 것이다. 이 개념들은 각자의 범위와 생명 주기를 가지고 있다.
persistence context(지속화 상하문)
데이터베이스 트랜잭션 (사무)
@Transactional 자체는 하나의 업무 범위를 정의합니다.이 업무는persistencecontext의 범위 내에 있습니다.
JPA의 지속화 상하문은 Entity Manager로 내부적으로 Hibernate Session(Hibernate를 지속화 provider로 사용)을 사용합니다.
지속화 상하문은 단지 하나의 동기화 대상일 뿐, 유한하게 집합된 자바 대상의 상태를 기록하고 이러한 대상의 변화가 최종적으로 데이터베이스로 지속화되도록 보장한다.
이것은 단일 사무와 매우 다른 개념이다.하나의 Entity Manager는 여러 가지 업무를 뛰어넘어 사용할 수 있으며, 확실히 이렇게 사용된다.
Entity Manager는 언제 여러 트랜잭션을 뛰어넘습니까?
가장 흔히 볼 수 있는 상황은 Open Session In View 모드를 사용하여 게으름 초기화 이상을 처리할 때 이런 방법의 장점과 단점을 소개한 것이다.
이런 상황에서 도면층에서 실행되는 여러 개의 조회는 단일 사무의 업무 논리가 아니라 독립된 사무에 있지만, 이러한 조회는 같은entity 관리자가 관리한다.
또 다른 상황은 개발자가 지속화 상하문을 PersistenceContextType으로 표시하는 것이다.EXTENDED 는 여러 요청에 응답할 수 있음을 나타냅니다.
Entity Manager와 Transaction 간의 관계를 어떻게 정의합니까?
이것은 응용 개발자가 선택하지만, JPA Entity Manager가 가장 자주 사용하는 방식은 "Entity Manager per application transaction"(모든 업무는 자신의 실체 관리자) 모델이다.entity 관리자가 주입하는 일반적인 방법은 다음과 같다.

@PersistenceContext 
  privateEntityManager em; 

기본값은 Entity Manager per transaction 모드입니다.이 모드에서 @Transactional 방법 내부에서 이 Entity Manager를 사용하면 이 방법은 단일 업무에서 실행됩니다.
@PersistenceContext는 어떻게 작동합니까?
따라서 문제는 @PersistenceContext가 용기가 시작될 때만 entity 관리자를 주입하는 방법입니다. entity 관리자의 생명 주기가 매우 짧고 요청할 때마다 여러 개의 entity 관리자가 필요하다고 가정합니다.
답은 다음과 같다. Entity 관리자는 인터페이스이고spring bean에 주입된 것은 entity 관리자 자체가 아니라 실행할 때 구체적인 entity 관리자를 에이전트하는context aware proxy (상문 감지 에이전트) 이다.
일반적으로 에이전트에 사용되는 구체적인 종류는 Shared Entity Manager Invocation Handler로 디버거를 통해 확인할 수 있습니다.
그러면 @Transactional은 어떻게 작동합니까?
Entity Manager 인터페이스의 지속성을 실현하는 상하문 에이전트는 성명식 사무 관리의 유일한 부분이 아니라 사실상 세 가지 구성 부분을 포함한다.
Entity Manager Proxy 자체
사무의 단면
트랜잭션 관리자
이 세 부분과 그것들 사이의 상호작용을 봐라.
사무의 단면
사무의 절단면은'around(서라운드)'절단면으로 주석의 업무 방법 전후에 모두 호출될 수 있다.절단면을 실현하는 구체적인 종류는 TransactionInterceptor이다.
업무의 단면에는 두 가지 주요 직책이 있다.
'before'때, 호출된 업무 방법이 현재 업무를 진행하고 있는 범위 내에서 실행되어야 하는지, 아니면 새로운 독립된 업무를 시작해야 하는지를 결정하는 호출점을 제공합니다.
'after'때, 절단면은 업무가 제출되었는지, 스크롤되었는지, 계속 실행되었는지 확인해야 합니다.
'before'때 사무 절단면 자체는 어떠한 결정 논리도 포함하지 않고 새로운 사무를 시작할 것인지의 결정은 사무 관리자에게 위임되어 완성된다.
트랜잭션 관리자
트랜잭션 관리자는 다음 두 가지 문제를 해결해야 합니다.
새 Entity Manager가 생성되어야 합니까?
새로운 업무를 시작해야 합니까?
이것은 사무 절단면'before'논리가 호출될 때 결정됩니다.트랜잭션 관리자의 결정은 다음 두 가지를 기반으로 합니다.
작업이 진행 중입니까?
트랜잭션 방법의 propagation 속성(예를 들어 REQUIRES_NEW는 항상 새로운 트랜잭션을 시작합니다)
트랜잭션 관리자가 새 트랜잭션을 만들려고 하면 다음을 수행합니다.
1. 새로운 entity 관리자 만들기
2.entity 관리자가 현재 라인에 바인딩
3. 데이터베이스 연결 풀에서 연결 얻기
4. 연결을 현재 라인에 바인딩
ThreadLocal 변수를 사용하여 entity 관리자와 데이터베이스 연결을 현재 라인에 연결합니다.
사무가 실행될 때 그들은 라인에 저장되고, 더 이상 사용되지 않을 때, 사무 관리자는 그들을 제거할지 여부를 결정합니다.
프로그램의 모든 부분을 현재entity 관리자와 데이터베이스 연결이 필요하면 라인에서 얻을 수 있습니다.
EntityManager proxy
Entity Manager proxy가 바로 수수께끼의 마지막 부분입니다.업무 방법이 entity 관리자를 호출할 때.persist () 시, 이것은 entity 관리자가 직접 호출하는 것이 아닙니다.
업무 방법은 에이전트를 호출합니다. 에이전트는 라인에서 현재entity 관리자를 가져옵니다. 앞에서 사무 관리자가 entity 관리자를 라인에 연결하는 것을 소개했습니다.
@Transactional 메커니즘의 각 부분을 알아보고 일반적인 Spring 설정을 실현하는 것을 살펴보겠습니다.
세 부분을 통합하다
어떻게 세 부분을 조합하여 사무 주석이 정확하게 역할을 발휘할 수 있습니까?우선 entity 관리자 공장을 정의합니다.
이렇게 하면 상하문 주석을 지속화하여 Entity Manager proxy를 주입할 수 있다.

@Configuration 
  publicclass EntityManagerFactoriesConfiguration {
	@Autowired 
	    privateDataSource dataSource;
	@Bean(name = "entityManagerFactory") 
	    publicLocalContainerEntityManagerFactoryBean emf() {
		LocalContainerEntityManagerFactoryBean emf = ... 
		      emf.setDataSource(dataSource);
		emf.setPackagesToScan( 
		        newString[] {
			"your.package"
		}
		);
		emf.setJpaVendorAdapter( 
		        newHibernateJpaVendorAdapter());
		returnemf;
	}
}

다음 단계는 사무 관리자를 설정하고 @Transactional 주석 클래스에서 사무를 적용하는 절단면을 실현합니다.

@Configuration 
  @EnableTransactionManagement 
  publicclass TransactionManagersConfig {
	@Autowired 
	    EntityManagerFactory emf;
	@Autowired 
	    privateDataSource dataSource;
	@Bean(name = "transactionManager") 
	    publicPlatformTransactionManager transactionManager() {
		JpaTransactionManager tm =  
		        newJpaTransactionManager();
		tm.setEntityManagerFactory(emf);
		tm.setDataSource(dataSource);
		returntm;
	}
}

메모 @EnableTransactionManagement 알림Spring, @Transactional 메모의 클래스는 트랜잭션의 탄젠트에 둘러싸여 있습니다.이렇게 @Transactional을 사용하면 사용할 수 있습니다.
총결산
Spring 선언식 트랜잭션 관리 메커니즘은 매우 강력하지만, 잘못 사용되거나 구성 오류가 발생할 수 있습니다.
이 메커니즘이 정상적으로 작동하지 못하거나 예상한 운행 결과에 미치지 못하는 문제가 발생할 때 그 내부 작업 상황을 이해하는 것이 도움이 된다.
기억해야 할 가장 중요한 것은 두 가지 개념을 고려해야 한다는 것이다. 그것이 바로 사무와 지속화 상하문이다. 각각 자신이 읽을 수 없는 뚜렷한 생명주기가 있다는 것이다.
이상은 본고에서 Spring @Transactional의 작업 원리에 대한 상세한 설명의 전부입니다. 여러분께 도움이 되기를 바랍니다.관심 있는 친구는 본 사이트의 다른 관련 주제를 계속 참고할 수 있습니다. 부족한 점이 있으면 댓글로 지적해 주십시오.여러분의 본 사이트에 대한 지지에 감사 드립니다!