Spring에서 @Transactional 사용법 상세 설명

9583 단어 Spring@Transactional
Spring에서 @Transactional 사용법 상세 설명
인용:spring에서 @Transactional은 사무 관리를 제어하는 빠른 수단을 제공하지만 많은 사람들이 @Transactional만 간단하게 사용하고 그 각 설정 항목의 사용 방법을 깊이 이해하지 못한다. 본고는 각 설정 항목의 사용을 깊이 있게 설명하고자 한다.
1. @Transactional 정의
Spring의 @Transactional은 동적 에이전트의 메커니즘을 바탕으로 투명한 사무 관리 메커니즘을 제공하여 개발 과정에서 부딪히는 문제를 신속하게 해결할 수 있습니다.현실에서 실제 문제는 우리가 예상한 것보다 훨씬 복잡하다. 이것은 @Transactional에 대해 깊이 있게 이해하고 복잡한 문제에 대처해야 한다.
우선 @Transactional의 코드 정의를 살펴보겠습니다.

@Target({ElementType.METHOD, ElementType.TYPE}) 
@Retention(RetentionPolicy.RUNTIME) 
@Inherited 
@Documented 
public @interface Transactional { 
 
  /** 
   * A qualifier value for the specified transaction. 
   * <p>May be used to determine the target transaction manager, 
   * matching the qualifier value (or the bean name) of a specific 
   * {@link org.springframework.transaction.PlatformTransactionManager} 
   * bean definition. 
   */ 
  String value() default ""; 
 
  /** 
   * The transaction propagation type. 
   * Defaults to {@link Propagation#REQUIRED}. 
   * @see org.springframework.transaction.interceptor.TransactionAttribute#getPropagationBehavior() 
   */ 
  Propagation propagation() default Propagation.REQUIRED; 
 
  /** 
   * The transaction isolation level. 
   * Defaults to {@link Isolation#DEFAULT}. 
   * @see org.springframework.transaction.interceptor.TransactionAttribute#getIsolationLevel() 
   */ 
  Isolation isolation() default Isolation.DEFAULT; 
 
  /** 
   * The timeout for this transaction. 
   * Defaults to the default timeout of the underlying transaction system. 
   * @see org.springframework.transaction.interceptor.TransactionAttribute#getTimeout() 
   */ 
  int timeout() default TransactionDefinition.TIMEOUT_DEFAULT; 
 
  /** 
   * {@code true} if the transaction is read-only. 
   * Defaults to {@code false}. 
   * <p>This just serves as a hint for the actual transaction subsystem; 
   * it will <i>not necessarily</i> cause failure of write access attempts. 
   * A transaction manager which cannot interpret the read-only hint will 
   * <i>not</i> throw an exception when asked for a read-only transaction. 
   * @see org.springframework.transaction.interceptor.TransactionAttribute#isReadOnly() 
   */ 
  boolean readOnly() default false; 
 
  /** 
   * Defines zero (0) or more exception {@link Class classes}, which must be a 
   * subclass of {@link Throwable}, indicating which exception types must cause 
   * a transaction rollback. 
   * <p>This is the preferred way to construct a rollback rule, matching the 
   * exception class and subclasses. 
   * <p>Similar to {@link org.springframework.transaction.interceptor.RollbackRuleAttribute#RollbackRuleAttribute(Class clazz)} 
   */ 
  Class<? extends Throwable>[] rollbackFor() default {}; 
 
  /** 
   * Defines zero (0) or more exception names (for exceptions which must be a 
   * subclass of {@link Throwable}), indicating which exception types must cause 
   * a transaction rollback. 
   * <p>This can be a substring, with no wildcard support at present. 
   * A value of "ServletException" would match 
   * {@link javax.servlet.ServletException} and subclasses, for example. 
   * <p><b>NB: </b>Consider carefully how specific the pattern is, and whether 
   * to include package information (which isn't mandatory). For example, 
   * "Exception" will match nearly anything, and will probably hide other rules. 
   * "java.lang.Exception" would be correct if "Exception" was meant to define 
   * a rule for all checked exceptions. With more unusual {@link Exception} 
   * names such as "BaseBusinessException" there is no need to use a FQN. 
   * <p>Similar to {@link org.springframework.transaction.interceptor.RollbackRuleAttribute#RollbackRuleAttribute(String exceptionName)} 
   */ 
  String[] rollbackForClassName() default {}; 
 
  /** 
   * Defines zero (0) or more exception {@link Class Classes}, which must be a 
   * subclass of {@link Throwable}, indicating which exception types must <b>not</b> 
   * cause a transaction rollback. 
   * <p>This is the preferred way to construct a rollback rule, matching the 
   * exception class and subclasses. 
   * <p>Similar to {@link org.springframework.transaction.interceptor.NoRollbackRuleAttribute#NoRollbackRuleAttribute(Class clazz)} 
   */ 
  Class<? extends Throwable>[] noRollbackFor() default {}; 
 
  /** 
   * Defines zero (0) or more exception names (for exceptions which must be a 
   * subclass of {@link Throwable}) indicating which exception types must <b>not</b> 
   * cause a transaction rollback. 
   * <p>See the description of {@link #rollbackForClassName()} for more info on how 
   * the specified names are treated. 
   * <p>Similar to {@link org.springframework.transaction.interceptor.NoRollbackRuleAttribute#NoRollbackRuleAttribute(String exceptionName)} 
   */ 
  String[] noRollbackForClassName() default {}; 
 
} 
원본 코드를 바탕으로 @Transactional에서 원래 이렇게 많은 속성을 설정할 수 있어 복잡한 응용 제어의 목적을 달성할 수 있음을 알 수 있다.구체적인 각 속성의 용법과 작용은 본고의 뒤에서 하나하나 설명하고 설명할 것이다.
2. @Transactional Spring 구성 사용
@Transactional 기반 트랜잭션 관리를 사용하려면 Spring에서 다음과 같이 구성해야 합니다.

 <beans:bean id="transactionManager" 
  class="org.springframework.orm.jpa.JpaTransactionManager"> 
  <beans:property name="dataSource" ref="dataSource" /> 
  <beans:property name="entityManagerFactory" ref="entityManagerFactory" /> 
</beans:bean> 
 
<!--   --> 
<tx:annotation-driven transaction-manager="transactionManager" /> 
DataSource는 Spring 프로필에 정의된 데이터 원본의 대상 실례이며, Entity Manager Factory는 JPA를 기반으로 하는 실체 클래스 관리자: org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.이것들은 모두 데이터베이스와의 연결 정보를 설정하는 데 사용되며, 본질적으로 @Transactional은 JDBC의 사무를 사용하여 사무 제어를 한다.
탭의 성명은 스프링 내부에서 @Transactional을 사용하여 사무 관리를 하는 것입니다. 스위치와 같은 성명입니다.
3. @Transactional의 value
value는 주로 서로 다른 사무 관리자를 지정하는 데 사용됩니다.주로 같은 시스템에 서로 다른 사무 관리자가 존재하는 것을 만족시키는 데 쓰인다.예를 들어 Spring에서 두 가지 사무 관리자 txManager1, txManager2를 성명했다.
그리고 사용자는 이 매개 변수에 따라 필요에 따라 특정한 txManager를 지정할 수 있습니다.
그럼 어떤 상황에서 여러 개의 사무 관리자가 존재하는지 물어볼 학생이 있을까요?예를 들어 한 시스템에서 여러 개의 데이터 원본이나 여러 개의 데이터베이스에 접근해야 한다면 반드시 여러 개의 사무 관리자를 설정할 것이다.
4. @Transactional propagation
Propagation은 다음과 같은 7가지 전파 메커니즘을 지원합니다.
 REQUIRED
업무 방법은 하나의 업무에서 실행되어야 합니다. 만약 방법이 실행될 때, 이미 하나의 업무에 처해 있다면, 이 업무에 가입하십시오. 그렇지 않으면 새로운 업무를 만들 것입니다.이것은 스프링의 기본 전파 행위입니다.. 
 SUPPORTS:  
만약에 업무 방법이 특정한 사무 범위 내에서 호출된다면 방법은 이 사무의 일부가 되고, 업무 방법이 사무 범위 밖에서 호출된다면 방법은 사무가 없는 환경에서 집행된다.
 MANDATORY:
이미 존재하는 사무에서만 실행할 수 있으며, 업무 방법은 자신의 사무를 발기할 수 없다. 만약 업무 방법이 사무가 없는 환경에서 호출된다면 이상을 던진다
 REQUIRES_NEW
업무 방법은 항상 자신을 위해 새로운 사무를 발기하는데, 만약 방법이 하나의 사무에서 실행된다면, 원래의 사무가 중단되고, 새로운 사무가 만들어지고, 방법이 끝날 때까지, 새로운 사무가 끝나야만 원래의 사무가 실행을 회복할 수 있다.
 NOT_SUPPORTED
성명 방법은 업무가 필요합니다. 만약 방법이 하나의 업무와 관련이 없다면, 용기는 그것을 위해 업무를 열지 않습니다.만약 방법이 하나의 업무에서 호출된다면, 이 업무는 중단되고, 방법 호출이 끝난 후, 원래의 업무는 실행을 회복할 것이다.
NEVER:
성명 방법은 절대로 사무 범위 내에서 집행할 수 없으며, 만약 방법이 어떤 사무 범위 내에서 집행된다면 용기는 이상을 던진다.사무와 관련이 없어야만 정상적으로 집행할 수 있다.
 NESTED:
만약 활동적인 업무가 존재한다면, 끼워 넣은 업무에서 실행됩니다.활성 트랜잭션이 없으면 REQUIRED 속성에 따라 수행됩니다.그것은 하나의 단독 사무를 사용했는데, 이 사무는 여러 개의 굴러갈 수 있는 보증점을 가지고 있다.내부 트랜잭션 롤백은 외부 트랜잭션에 영향을 주지 않으며 DataSourceTransactionManager 트랜잭션 관리자에만 적용됩니다.
사실 여러분들이 가장 당혹스러워하는 건 리퀴어드 입니다.NEW와 NESTED의 두 가지 서로 다른 전파 메커니즘은 기능이 유사하고 모두 사무 끼워 넣는 문제와 관련된다. 그러면 두 가지는 어떤 차이가 있습니까?어떻게 이 두 가지 모델을 정확하게 사용해야 합니까?
다음은 Spring에서 발췌한 문서입니다.

  PROPAGATION_REQUIRES_NEW : uses a completely independent transaction for
 each affected transaction scope. In that case, the underlying physical 
transactions are different and hence can commit or roll back independently, 
with an outer transaction not affected by an inner transaction's rollback status.
내부의 사무가 독립적으로 운행되고 각자의 역할 영역에서 독립적으로 굴러가거나 제출할 수 있다.외부 사무는 내부 사무의 굴림 상태에 영향을 받지 않는다.   

 ROPAGATION_NESTED : uses a single physical transaction with multiple 
savepoints that it can roll back to. Such partial rollbacks allow an
 inner transaction scope to trigger a rollback for its scope, with the outer 
transaction being able to continue the physical transaction despite some operations 
having been rolled back. This setting is typically mapped onto JDBC savepoints, so will 
only work with JDBC resource transactions.
NESTED의 사무는 단일한 사무를 바탕으로 관리하며 여러 개의 저장점을 제공한다.이런 여러 개의 저장점의 메커니즘은 내부 업무의 변경이 외부 업무의 롤백을 촉발하도록 허용한다.외부 업무는 스크롤된 후에도 일부 작업이 스크롤되었더라도 계속 처리할 수 있다.이 설정은 JDBC의 저장점을 기반으로 하기 때문에 JDBC의 메커니즘 IQ에서만 작동할 수 있습니다.
이로부터 알 수 있듯이 둘 다 사무가 끼워져 있고 다른 점은 내외 사무 사이에 서로 간의 영향이 존재하는지 여부이다.NESTED 간에 영향을 받고 롤백 부분이 발생하며 REQUIRED_뉴는 독립적이다.
읽어주셔서 감사합니다. 여러분에게 도움이 되었으면 좋겠습니다. 본 사이트에 대한 지지에 감사드립니다!

좋은 웹페이지 즐겨찾기