@Transactional 의 동작원리, 트랜잭션 매니저

💭 JDBC에서 사용하는 트랜잭션

자바의 JDBC에서 개발자가 직접 트랜잭션을 관리하는 방법은 한가지 밖에 없습니다.

// 커넥션 풀에서 DB커넥션을 받아왔다고 가정
Connection connection = dataSource.getConnection();

try (connection) {
    connection.setAutoCommit(false); // 자동 커밋 off
    // ...DB 작업...
    connection.commit(); // 성공시 트랜잭션 커밋
} catch (SQLException e) {
    connection.rollback(); // 오류 발생시 트랜잭션 롤백
}

JDBC가 작동되는 과정. DAO는 사용자가 직접 만든 코드 (DataAccessObject)

우리가 사용하는 Spring와 하이버네이트에서 제공해주는 @Transactional는 알아서 트랜잭션을 관리해주는 마법의 키워드가 아닙니다. 추상화해서 사용할 뿐이지 실제는 위의 코드처럼 JDBC 트랜잭션을 사용하여 구현합니다.

 

---

💭Spring의 @Transactional

스프링에서 트랜잭션 처리를 하고자하면 아래와 어노테이션을 메서드에 붙이면 됩니다.

@Transactional(propagation = TransactionDefinition.NESTED, 
        isolation = TransactionDefinition.ISOLATION_READ_UNCOMMITTED)

전파옵션 예제(propagation)

@SpringBootTest
class UserServiceTest {
    
    /* ... */

    @Autowired
    UserService userService;

    User setUpUser;

    @BeforeEach
    void setUp() {
        setUpUser = userService.save("set-up-nickname", 20);
    }

    @Test
    @DisplayName("Non Transactional")
    void changeNicknameTest() {
        String nickname = "sample-nickname";
        int age = 20;
        User savedUser = userService.save(nickname, age);

        /*
        * INSERT USER
        * */

        String newNickname = "new-nickname";
        User findUser = userService.changeNickname(savedUser.getId(), newNickname);

        /*
        * UPDATE USER
        * */

        /*
        * savedUser = {User@9086}
        *   id = 9
        *   nickname = "sample-nickname"
        *   age = 20
        *
        * findUser = {User@9146}
        *   id = 9
        *   nickname = "new-nickname"
        *   age = 20
        * */

        assertEquals(newNickname, findUser.getNickname());
        assertNotEquals(newNickname, savedUser.getNickname());
        assertEquals(findUser.getId(), savedUser.getId());
        assertNotEquals(findUser, savedUser);

        /*
        * No Rollback
        * */
    }

    @Test
    @DisplayName("Propagation: Required (기본 세팅 값. 현재 트랜잭션이 존재하면 이어서 받아들이고, 존재하지 않는다면 새로운 트랜잭션을 시작)")
    @Transactional
    void changeNicknameAsRequiredTransactionalTest() {
        String nickname = "sample-nickname";
        int age = 20;
        User savedUser = userService.save(nickname, age);

        /*
        * No INSERT USER
        * */

        String newNickname = "new-nickname";
        User findUser = userService.changeNickname(savedUser.getId(), newNickname);

        /*
        * No UPDATE USER
        * */

        /*
        * savedUser = {User@9055}
        *   id = 11
        *   nickname = "new-nickname"
        *   age = 20
        *
        * findUser = {User@9055}
        *   id = 11
        *   nickname = "new-nickname"
        *   age = 20
        * */

        assertEquals(findUser, savedUser);

        /*
        * Rollback Well
        * */
    }

    @Test
    @DisplayName("Propagation: Supports (현재 트랜잭션이 존재하면 이어서 받아들이고, 존재하지 않는다면 굳이 생성하지 않고 Non-트랜잭션 상태로 실행)")
    @Transactional(propagation = Propagation.SUPPORTS)
    void changeNicknameAsSupportsTransactionalTest() {
        String nickname = "sample-nickname";
        int age = 20;
        User savedUser = userService.save(nickname, age);

        /*
        * INSERT USER
        * */

        String newNickname = "new-nickname";
        User findUser = userService.changeNickname(savedUser.getId(), newNickname);

        /*
        * UPDATE USER
        * */

        /*
        * savedUser = {User@9086}
        *   id = 6
        *   nickname = "sample-nickname"
        *   age = 20
        *
        * findUser = {User@9151}
        *   id = 6
        *   nickname = "new-nickname"
        *   age = 20
        * */

        assertEquals(newNickname, findUser.getNickname());
        assertNotEquals(newNickname, savedUser.getNickname());
        assertEquals(findUser.getId(), savedUser.getId());
        assertNotEquals(findUser, savedUser);

        /*
        * No Rollback
        * */
    }

    /*
    * 현재 트랜잭션이 존재하면 이어서 받아들이고, 존재하지 않는다면 예외를 던진다.
    * */
    @Test
    @DisplayName("Propagation - Mandatory")
    @Transactional(propagation = Propagation.MANDATORY)
    void changeNicknameAsMandatoryTransactionalTest() {
        /*
        * IllegalTransactionStateException 발생
        * */
        System.out.println("실행 될까?");
    }

    @Test
    @DisplayName("Propagation: Requires New (현재 트랜잭션이 존재하면 중단하고, 새로운 트랜잭션을 시작)")
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    void changeNicknameAsRequiresNewTransactionalTest() {
        String nickname = "sample-nickname";
        int age = 20;
        User savedUser = userService.save(nickname, age);

        /*
        * No INSERT USER
        * */

        String newNickname = "new-nickname";
        User findUser = userService.changeNickname(savedUser.getId(), newNickname);

        /*
        * No UPDATE USER
        * */

        /*
        * savedUser = {User@9055}
        *   id = 8
        *   nickname = "new-nickname"
        *   age = 20
        *
        * findUser = {User@9055}
        *   id = 8
        *   nickname = "new-nickname"
        *   age 20
        * */

        assertEquals(findUser, savedUser);

        /*
        * Rollback Well
        * */
    }

    @Test
    @DisplayName("Propagation: Not Supported (현재 트랜잭션이 존재하면 중단시키고, Non-트랜잭션 상태로 실행)")
    @Transactional(propagation = Propagation.NOT_SUPPORTED)
    void changeNicknameAsNotSupportedTransactionalTest() {
        String nickname = "sample-nickname";
        int age = 20;
        User savedUser = userService.save(nickname, age);

        /*
         * INSERT USER
         * */

        String newNickname = "new-nickname";
        User findUser = userService.changeNickname(savedUser.getId(), newNickname);

        /*
         * UPDATE USER
         * */

        /*
         * savedUser = {User@9086}
         *   id = 15
         *   nickname = "sample-nickname"
         *   age = 20
         *
         * findUser = {User@9145}
         *   id = 15
         *   nickname = "new-nickname"
         *   age = 20
         * */

        assertEquals(newNickname, findUser.getNickname());
        assertNotEquals(newNickname, savedUser.getNickname());
        assertEquals(findUser.getId(), savedUser.getId());
        assertNotEquals(findUser, savedUser);

        /*
         * No Rollback
         * */
    }

    @Test
    @DisplayName("Propagation: Never (현재 트랜잭션이 존재하면 예외를 던지고, Non-트랜잭션 상태로 실행)")
    @Transactional(propagation = Propagation.NEVER)
    void changeNicknameAsNeverTransactionalTest() {
        String nickname = "sample-nickname";
        int age = 20;
        User savedUser = userService.save(nickname, age);

        /*
         * INSERT USER
         * */

        String newNickname = "new-nickname";
        User findUser = userService.changeNickname(savedUser.getId(), newNickname);

        /*
         * UPDATE USER
         * */

        /*
         * savedUser = {User@9086}
         *   id = 16
         *   nickname = "sample-nickname"
         *   age = 20
         *
         * findUser = {User@9145}
         *   id = 16
         *   nickname = "new-nickname"
         *   age = 20
         * */

        assertEquals(newNickname, findUser.getNickname());
        assertNotEquals(newNickname, savedUser.getNickname());
        assertEquals(findUser.getId(), savedUser.getId());
        assertNotEquals(findUser, savedUser);

        /*
         * No Rollback
         * */
    }

    @Test
    @DisplayName("Propagation: Nested (현재 트랜잭션이 존재하면 중첩된 트랜잭션을 생성하여 실행하고, 현재 트랜잭션이 존재하지 않으면 Required와 동일하게 동작)")
    @Transactional(propagation = Propagation.NESTED)
    void changeNicknameAsNestedTransactionalTest() {
        String nickname = "sample-nickname";
        int age = 20;
        User savedUser = userService.save(nickname, age);

        /*
         * No INSERT USER
         * */

        String newNickname = "new-nickname";
        User findUser = userService.changeNickname(savedUser.getId(), newNickname);

        /*
         * No UPDATE USER
         * */

        /*
         * savedUser = {User@9055}
         *   id = 17
         *   nickname = "new-nickname"
         *   age = 20
         *
         * findUser = {User@9055}
         *   id = 17
         *   nickname = "new-nickname"
         *   age 20
         * */

        assertEquals(findUser, savedUser);

        /*
         * Rollback Well
         * */
    }

}

이렇게 단순한 설정변수 하나로 트랜잭션의 propagation level과 isolation level을 지정할 수 있습니다. 마법처럼 보이지만, 결국 실제로는 제일 처음본 JDBC코드와 동일하게 동작합니다.

// isolation=TransactionDefinition.ISOLATION_READ_UNCOMMITTED
connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);

// propagation=TransactionDefinition.NESTED
Savepoint savePoint = connection.setSavepoint();

...
connection.rollback(); // 오류 발생시 트랜잭션 롤백

 

---

💭스프링의 마술, Transaction Management

📌 스프링의 추상화, PlatformTranscationManager

스프링은 트랜잭션 처리를 TranscationManager 객체를 통해 처리합니다.

구현체는 갈아끼울 수 있게 인터페이스인 PlatformTranscationManager가 주입되어 사용됩니다.

// 깔-끔. 
public interface PlatformTransactionManager {
    TransactionStatus getTransaction(@Nullable TransactionDefinition var1) throws TransactionException;

    void commit(TransactionStatus var1) throws TransactionException;

    void rollback(TransactionStatus var1) throws TransactionException;
}

물론 구현체마다 거의 동일한 부분이 있을 수 있어서, 이를 구현하는 AbstarctPlatformTxManager가 존재합니다.

참고로 기본 구현체는 DataSourceTxManager이고, SpringDataJPA 사용시 JpaTxManager로 설정을 바꿉니다.

 

초기 스프링은 XML을 빈을 생성하여 관리했었습니다.

하지만 이는 매우 불편하고 코드와 설정파일을 매번 맞춰주어야해서, 최근에는 거의 쓰지않는 방법입니다.

</beans> <!-- 이렇게 설정했었답니다. 최근에는 yaml이나 @어노테이션, 자바코드로 직접 설정하죠.-->

<!-- dataSource 설정, spring-jdbc 모듈 사용, spring 에서 jdbc 를 통해 mysql 에 접속할 수 있게 함 -->
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver"></property> 
    <property name="url" value="jdbc:mysql://35.200.109.72:3306/testdb?useSSL=false"></property>
    <property name="username" value="root"></property>
    <property name="password" value="비~밀"></property>
</bean>		
 
   <bean id="jdbcTemplate" class="org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate">
     <constructor-arg ref="dataSource"></constructor-arg>  
   </bean>
   
   <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
   	<property name="dataSource" ref="dataSource"/>
   </bean>
</beans>

 

 

최근에는 yaml 같은 설정 파일과 자바코드로 쉽게 설정할 수 있죠.

spring:
  datasource:
    url: jdbc:h2:tcp://주소:포트/...
    username: 아이디
    password: 비밀번호
    driver-class-name: org.h2.Driver

@Configuration
public class DatabaseConfiguration {

    @Bean
    public SqlSessionFactory sqlSessionFactory(DataSource dataSource) throws Exception {
        var factoryBean = new SqlSessionFactoryBean();
        var configuration = new org.apache.ibatis.session.Configuration();
        
        configuration.setMapUnderscoreToCamelCase(true);
        factoryBean.setDataSource(dataSource);
        factoryBean.setConfiguration(configuration);
        
        var resolver = new PathMatchingResourcePatternResolver();
        factoryBean.setMapperLocations(resolver.getResources("classpath:mapper/xml/*.xml"));
        return factoryBean.getObject();
    }

}

 

참고로 테스트 용도로 쓰이는 인메모리 DB는, Datasource를 설정하지 않아도 바로 사용이 가능합니다.

이는 SpringBoot에 있는 @AutoConfiguration에 의해 DataSource와 JdbcTemplate이 빈으로 생성되기 때문입니다.
물론 해당 인메모리 DB Driver 의존성은 있어야 자동설정 됩니다. 스프링은 마술이 아니에요.
생성된 DataSource는 의존성으로 주입받아서 확인해볼 수 있습니다.

@Slf4j
@Component
/* 참고로 스프링 앱 실행후, 어떠한 코드를 실행하고 싶다면 ApplicationRunner.run()을 사용하면 됩니다. */
public class TestRunner implements ApplicationRunner {
    @Autowired
    DataSource dataSource;

    @Override
    public void run(
        ApplicationArguments args) throws Exception {
        Connection connection = dataSource.getConnection();

        log.info("Url: " + connection.getMetaData().getURL());
        log.info("UserName: " + connection.getMetaData().getUserName()); 
        // INFO --- [ main] TestRunner : Url: jdbc:h2:mem:testdb
        // INFO --- [ main] TestRunner : UserName: SA
    }
}

 

 

📌 사용법1 - TransactionTemplate 사용

스프링의 IoC, AOP를 사용하지 않고, 코드로 직접 사용하는 방법입니다. 보통 TransactionTemplate을 사용합니다. (기억하세요, 이 객체는 내부에서 PlatformTransactionManager를 사용하고 있습니다.)

@Service
public class UserService {
    @Autowired
    private TransactionTemplate template;

    public Long registerUser(User user) {
        Long id = template.execute(status -> {
            // SQL 실행
            return id;
        });
    }
}

이 방법은 아래와 같은 장점이 있습니다.

• 스프링 IoC를 통해 설정영역과 DB실행코드가 분리되었습니다. 설정을 수정할 필요가 없습니다.
• 데이터베이스 커넥션을 개발자가 관리하지 않습니다. 개발자는 트랜잭션 콜백 메서드만 구현하면 됩니다.
• 저수준의 SQLExceptions을 스프링에서 잡아 추상화된 런타임 예외로 포장해줍니다.

 

물론 @Transcational이 상당히 편하기 때문에, 잘 사용하는 방법은 아닙니다.

하지만 다이나믹 프록시의 원리상, @Transcational의 경우 클래스나 메서드 단위로 밖에 걸 수 없습니다.
예를 들어 [상품구매-이메일발송]인데, 이메일 발송이 취소되었다고 트랜잭션에 의해 롤백되면 안됩니다.

이런 경우 @Transcational 으로 해결하기엔 애매한 상황이 나옵니다. DIP를 무시하고 도메인에 붙인다거나..

public class TransactionInvoker {

    private A1Dao a1dao;
    private A2Dao a2dao;

    @Transactional
    public void doInternalTransaction() throws Exception{
        a1dao.insertA1();
        a2dao.insertA2();
    }
}

• 프록시의 특성상, 트랜잭션은 외부에서 doInternalTranscation()을 호출할 때만 걸립니다.
• 스프링 트랜잭션은 메서드 시작시 커넥션이 생성되고, 메서드 종료시에 커넥션을 풀에 반환합니다.

트랜잭션을 세부적으로 걸고싶다면, 아래와 같이 TranscationTemplate을 사용하면 됩니다.

@Transcational에서 지원하는 옵션은 당연히 Template에도 있습니다.
propagation : 트랜잭션 전파 규칙 설정
isolation : 트랜잭션 격리 레벨 설정
readOnly : 읽기 전용 여부 설정
rollbackFor : 트랜잭션을 롤백할 예외 타입 설정
noRollbackFor : 트랜잭션을 롤백하지 않을 예외 타입 설정
timeout : 트랜잭션 타임아웃 시간 설정

public class TransactionInvoker {

    private A1Dao a1dao;
    private A2Dao a2dao;
    private TransactionTemplate transactionTemplate;

    public void setTransactionManager(PlatformTransactionManager transactionManager) {
        // @Transcational(...)의 설정은 이렇게 할 수 있다.
        this.transactionTemplate = new TransactionTemplate(transactionManager);
        this.transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
        this.transactionTemplate.setTimeout(30);
    }

    private void doInternalTransaction() throws Exception {
        transactionTemplate.execute(new TransactionCallbackWithoutResult() {
            public void doInTransactionWithoutResult(TransactionStatus status) {
                try {
                    a1dao.insertA1();
                    a2dao.insertA2();
                } catch (Exception e) {
                    status.setRollbackOnly(); // 콜백에서 실행된 코드만 롤백
                }
            }
        });
    }
}

 

참고로 반환값이 있는 트랜잭션(TranscationCallback)은 .execute() 메서드의 반환값으로 전달됩니다.

람다표현식이 사용 가능한경우, 아래와 같이 작성하면 더 간결합니다.

transactionTemplate.execute((TransactionCallback) status -> {
    try {
        a1dao.insertA1();
        a2dao.insertA2();
    } catch (Exception e) {
        status.setRollbackOnly();
    }
    return "Hello"; // tanscationTemplate.execute() 의 반환값
});

 

이런 경우 유용하게 사용할 수 있습니다.

// 프록시와 다르게 원하는 지점만 걸 수 있습니다. 말 그대로 직접 트랜잭션을 거는거니까요.
transactionTemplate.execute {
  val person = Person(name = "Suhwan Jee")
  personRepository.save(person) /* Spring Data JPA */

  try {
    transactionTemplate.execute {
      throw Exception("some unexpected exception")
    }
  } catch (e: Exception) {
  }
}

물론 @Transcational이나 TranscationTemplate이나 까보면 PlatformTxManager로 실행하는건 똑같습니다.
따로 동작하는게 아닙니다. + Spring Transcation Template을 사용할 때 실수하기 쉬운 부분들

Spring Transaction 사용 시 주의할 점

// TranscationTemplate의 내부코드
public class TransactionTemplate extends DefaultTransactionDefinition 
                                 implements TransactionOperations, InitializingBean {
    protected final Log logger = LogFactory.getLog(this.getClass());
    @Nullable
    private PlatformTransactionManager transactionManager;

    @Nullable
    public <T> T execute(TransactionCallback<T> action) throws TransactionException {
        Assert.state(this.transactionManager != null, "No PlatformTransactionManager set");
        if (this.transactionManager instanceof CallbackPreferringPlatformTransactionManager) {
            return ((CallbackPreferringPlatformTransactionManager)this.transactionManager).execute(this, action);
        } else {
			// PlatfromTranscationManger.getTransaction()을 통해 트랜잭션을 관리합니다.
            TransactionStatus status = this.transactionManager.getTransaction(this);

            Object result;
            try {
                result = action.doInTransaction(status);
            } catch (Error | RuntimeException var5) {
                this.rollbackOnException(status, var5);
                throw var5;
            } catch (Throwable var6) {
                this.rollbackOnException(status, var6);
                throw new UndeclaredThrowableException(var6, "TransactionCallback threw undeclared checked exception");
            }

            this.transactionManager.commit(status);
            return result;
        }
    }

 

---

@ 트랜잭션 어노테이션 사용 (@EnableTransactionManagement)

대부분의 개발자들은 이 방식을 선호합니다. @Transactional이 달린 메서드는 트랜잭션 처리가 되는거죠.

@Service
public class UserService {
    @Transactional
    public Long registerUser(User user) {
        // SQL 실행
        userDao.save(user);
        return id;
    }
}

• 트랜잭션 매니지먼트를 사용하기위해서는 컨테이너 객체에 @EnableTransactionManagement를 붙여야합니다.
  (최근에는 스프링부트의 @AutoConfiguration안에 기본 포함되어있습니다. 그래서 생략해도 동작하는거죠.)

@Configuration
@EnableTransactionManagement
public class AppConfig {
    @Bean // 모양만 다를뿐, 1번 방식과 똑같은 트랜잭션 매니저를 사용합니다.
    public PlatformTransactionManager txManager() {
        return yourTxManager; // more on that later 
    }
}​

• 그러면 스프링에서는 @Transactional 어노테이션이 달린 public 메서드에 대해 아래와 같은 트랜잭션 코드를 추가하여 실행해줍니다.

// 실제 스프링 내부에서 동작하는 JDBC 코드
public class UserService {
    public Long registerUser(User user) {
        Connection connection = dataSource.getConnection();
        
        try (connection) {
            connection.setAutoCommit(false);
            connection.commit();
            
        } catch (SQLException e) {
            connection.rollback();
        }
    }
}

 

물론 스프링이 프록시에 특정 dataSource를 직접 사용하지 않습니다.

PlatfromTxManager를 통해 DIP를 적용시켜놨죠. 구현체를 자유롭게 바꿀 수 있습니다.

---

# 스프링이 트랜잭션 코드를 내 객체에 추가하는 방법

이제 살살 느낌이 오시죠? 네. 스프링에서는 UserService 객체의 프록시에 트랜잭션 코드를 삽입합니다. 앞에서 배운 스프링 AOP를 사용해서 말이죠.

 

다만 여기에서 한가지 차이점은 프록시 자체에서 트랜잭션 코드를 실행하는 건 아니는 것입니다. 스프링 AOP는 프록시 객체에 다음과 같이 [Transaction Manager 객체]에게 위임하는 코드를 추가합니다.

• [Transaction Manager 객체]에는 doBegin() 과 doCommit() 메서드가 있습니다. 이를 통해 위임합니다.

// 이해를 돕기위한 트랜잭션매니저 객체의 코드. 실제 코드는 훨씬 복잡하다!
public class DataSourceTransactionManager implements PlatformTransactionManager {
    @Override
    protected void doBegin(Object transaction, TransactionDefinition definition) {
        //... 복잡한 과정 생략
        Connection newCon = obtainDataSource().getConnection();
        newCon.setAutoCommit(false);
    }

    @Override
    protected void doCommit(DefaultTransactionStatus status) {
        //... 복잡한 과정 생략
        Connection connection = status.getTransaction().getConnectionHolder().getConnection();
        try {
            con.commit();
        } catch (SQLException ex) {
            throw new TransactionSystemException("Could not commit JDBC transaction", ex);
        }
    }
}

 

@ 즉 정리하면 아래와 같습니다.

1. 스프링은 @Transactional 어노테이션을 가진 메서드를 발견하면, 다이나믹 프록시를 만듭니다.
2. 해당 프록시 객체는 [TransactionManager 객체]에게 트랜잭션 동작을 위임하는 코드를 가집니다.
3. 트랜잭션 매니저는 처음에 봤던 것 처럼 JDBC 코드를 통해 트랜잭션을 실행합니다.

스프링의 @Transcational은 마법의 키워드가 아닙니다. 결국 JDBC로 동작합니다. 이를 스프링에서는 @Transactional 태그를 이용한 논리적 트랜잭션을 사용하고, 실제 물리적 트랜잭션은 JDBC로 처리된다라고 표현하기도 합니다.

 

---

# @Transactional의 Propagtion을 구현하는 방법

사실 트랜잭션의 isolation level은 JDBC에서도 간단하게 설정할 수 있습니다.

다만 트랜잭션 도중 isolation level을 전환하고자 한다면 JDBC 드라이버에서 기능이 지원되는지 확인해야 합니다. 

// isolation=TransactionDefinition.ISOLATION_READ_UNCOMMITTED
connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);

 

그렇다면 Propagation은 대체 어떻게 JDBC로 만든 것일까요? 모든것의 비밀은 프록시를 통한 Lazy한 동작에 있습니다.

출처 https://jeong-pro.tistory.com/228

 

# (번외) @Transcational(readOnly = true)의 동작

성능을 향상시키는 @Transcational(readOnly=true)는 내부적으로 어떻게 동작하는 걸까?

물론 readOnly를 단다고 해서 특별하게 다른 동작이 일어나진 않는다.

어차피 @Transcational을 사용하는 시점에 setAutoCommit이 false가 되면서 여러 작업을 한 트랜잭션에 묶기 때문이다.

// 이해를 돕기위한 트랜잭션매니저 객체의 코드. 실제 코드는 훨씬 복잡하다!
public class DataSourceTransactionManager implements PlatformTransactionManager {
    @Override
    protected void doBegin(Object transaction, TransactionDefinition definition) {
        //... 복잡한 과정 생략
        Connection newCon = obtainDataSource().getConnection();
        newCon.setAutoCommit(false);
    }
    ...
}

다만 readOnly 라는 힌트를 주면, 스프링에서 성능 최적화를 위한 추가적인 작업을 약간 한다.(성능향상이 크지는 않다.)

JDBC 드라이버에 따라 다르지만. readOnly라고 판단되면 쿼리를 최적화하는 기능도 있다고 한다. 쿼리 힌트 같은 느낌

 

특히 JPA와 함께 사용할 때, SpringDataJpa에서는 readOnly가 설정되어있다면 영속성 컨텍스트를 플러시하지 않는다.

즉 플러시 모드가 강제로 Manual로 바뀌어버린다. (참고로 Manual의 과거이름은 Never였다. 플러시를 하지 않음.)

entityManager.setFlushMode(FlushModeType.MANUAL);

MANUAL = 난 플러시를 안한다. 니가 알아서 수동으로 해라

 

좀 더 쉽게말하면, 읽기 작업만 가능할 뿐 데이터베이스에 수정내역을 보내지 않는다.

 

(2022.08.15 추가)

* 참고로 더티체킹과 flush를 안한다고 했지, 트랜잭션의 readOnly가 수정/삭제를 막는 기능이 있지는 않다.
save()를 실행해도 잘 동작하고, updated의 경우에도 직접 flush 시켜주면 실제 DB에 쿼리가 찍힌다.

 

약간 비슷한 맥락으로, @Transcational( SUPPORTS )로 설정하면 추가되는 트랜잭션 관련 JDBC 코드는 아무것도 없다.

그래서 아래와 같이 순수 JDBC 코드를 섞어서 써도 충돌(예외)없이 정상적으로 데이터베이스에 전송됨을 알 수 있다.

@Transactional(readOnly = true, propagation=Propagation.SUPPORTS)
public long insertTrade(TradeData trade) throws Exception {
   //JDBC Code...
}

 

결국 전부다 자바와 JDBC 코드로 돌아가는거라서 그렇다. 내부동작을 알고있다면 크게 놀라운 부분도 아니다.

---

# Spring과 JPA에서 같은 @Transactional 태그를 사용할 수 있는 이유

어? 생각해보면 이상합니다. 스프링에서도 @Transactional 태그를 통한 프록시 생성이 있지만, JPA에도 독립적으로 해당 @Transactional 태그가 존재하고, 다른 처리방식이 존재합니다. 하지만 우리는 [스프링 + JPA] 조합을 문제없이 사용하는데 어떻게 동기화해서 사용하는 것일까요?

• 하이버네이트(JPA)는 스프링의 @Transactional의 동작방식을 모릅니다.
• 스프링은 하이버네이트(JPA)가 사용하는 @Transcational의 동작방식을 모릅니다.

public class UserService {
    @Autowired 
    private SessionFactory sessionFactory;
    
    // 하이버네이트(JPA)의 코드
    public void registerUser(User user) {
        Session session = sessionFactory.openSession();
        session.beginTransaction();
        session.save(user);
        session.getTransaction().commit();
        session.close();
    }
}

 

놀라운 사실은, 사실 별 문제가 없다는 겁니다. 이미 스프링에서 JPA와 함께 사용할 수 있게 자동화 해놓았습니다. 이게 어렵지 않게 가능한 것은 하이버네이트던 스프링이던 결국 둘 다 JDBC의 기본 방식을 사용하기 때문이죠.

추상화해서 쉽게 사용하는거지 마술이 아닙니다. 모든것은 JDBC로 동작합니다

 

---

# Spring과 하이버네이트를 함께 사용하는 방법

하이버네이트에서 제공하는 SessionFactory를 스프링에서 사용하고, @Transactional를 달아봅시다.이렇게 사용하면 스프링에서 상태를 관리하지 않고, 하이버네이트가 관리하도록 동작합니다.

@Service
public class UserService {
    @Autowired 
    private SessionFactory sessionFactory;

    @Transactional // 스프링과 하이버네이트가 같은 태그 사용.
    public void registerUser(User user) {
        sessionFactory.getCurrentSession().save(user);
    }
}

원리는 간단합니다. 스프링에서 프록시를 만들 때 스프링에서 사용하는 트랜잭션매니저 (PlatformTransactionManager)에게 위임하지 않고 하이버네이트의 트랜잭션 매니저 (HibernateTransactionManager)에게 위임하게 됩니다. 만약 JPA를 통해서 하이버네이트를 사용한다면 트랜잭션 매니저 객체로 (JpaTransactionManager)를 쓰면 되죠.

 

이는 원래 개발자가 직접 트랜잭션매니저 객체를 적절하게 지정해주어야했지만, 지금은 스프링 부트 라이브러리 (spring-boot-starter-data-jpa)를 쓰면 자동으로 Jpa 트랜잭션매니저를 쓰도록 설정을 바꿔줍니다.

 

스프링 내부 코드를 보지않았지만, 살짝 감이오시지 않나요? [트랜잭션 매니저 객체] 또한 IoC가 구현되어 유연하게 사용하고 있을거라는 느낌이요. 실제로 스프링은 PlatformTransactionManager 라는 인터페이스에만 의존하고 있고, 그 구현체는 유동적으로 바꿀 수 있습니다. 스프링에서 기본적으로 사용하는 구현체는 DataSourceTransactionManager 입니다.

 

---

# 결론

마법이 아닙니다. 하이버네이트를 쓰던 스프링을 쓰던 @Transactional을 쓰던 결국 데이터베이스 조작은 JDBC의 기본코드 (getConnection, setAutoCommit, Commit)으로 작동합니다. 

 

다만 이처럼 프록시를 사용해서 생기는 스프링의 트랜잭션 문제가 있는데, 이는 다른 글에서 따로 다뤄보도록 하겠습니다. 2021.08.18 - [Backend/Spring Core] - DB와 @Transactional을 사용할때 자주 나오는 실수

DB와 @Transactional을 사용할때 자주 나오는 실수

 

 

 

---

# 레퍼런스

https://www.marcobehler.com/guides/spring-transaction-management-transactional-in-depth?fbclid=IwAR1PsHPKHyLGmiKORaTsvXV6EwIwe5f2RTCkz52QLZFnDdI7QzArXLil4PQ
https://jeong-pro.tistory.com/228

 

 

# 2022.03.01 추가

📌Spring 은 @Transactional 어노테이션 붙인 메소드를 어떻게 찾고 트랜잭션을 처리하나요? 그 내부 구현을 상세하게 설명해 주세요.

일단 @Transcational은 컴포넌트 스캔의 대상이 아닙니다.

이는 @EnableTranscationManagement 를 기점으로, 하위 패키지들을 탐색한다.

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import({TransactionManagementConfigurationSelector.class})
public @interface EnableTransactionManagement {
    boolean proxyTargetClass() default false;
    AdviceMode mode() default AdviceMode.PROXY;
    int order() default 2147483647;
}

@Import(TransactionManagementConfigurationSelector.class) ➡ Selector를 스프링 빈으로 등록한다.
Selector는 3가지 종류의 @Transcational 어노테이션(javax, spring, aspectj)를 분류하는 기능을 가지고 있다.

public class TransactionManagementConfigurationSelector extends AdviceModeImportSelector<EnableTransactionManagement> {
    public TransactionManagementConfigurationSelector() {
    }

    protected String[] selectImports(AdviceMode adviceMode) {
        switch(adviceMode) {
        case PROXY:
            return new String[]{AutoProxyRegistrar.class.getName(), ProxyTransactionManagementConfiguration.class.getName()};
        case ASPECTJ:
            return new String[]{this.determineTransactionAspectClass()};
        default:
            return null;
        }
    }

    private String determineTransactionAspectClass() {
        return ClassUtils.isPresent("javax.transaction.Transactional", this.getClass().getClassLoader()) ? "org.springframework.transaction.aspectj.AspectJJtaTransactionManagementConfiguration" : "org.springframework.transaction.aspectj.AspectJTransactionManagementConfiguration";
    }
}

@EnableTranscationManagement는 기본적으로 PlatformTxManager 타입으로 등록된 빈을 찾아서 사용한다.

스프링부트는 DataSourceTxManager를 기본으로 등록해주고, SpringDataJPA 사용시 JpaDataSourceTxManager를 등록한다. 만약 TranscationTemplate처럼, 트랜잭션 매니저의 구현체를 바꾸고 싶거나, 여러개를 쓴다면 직접 지정하면 된다.

 

설정 객체에 TranscationConfigurer 인터페이스를 추가하면 된다.

@Configuration
@EnableTransactionManagement
public class DBConfig implements TransactionManagementConfigurer {

 // 생략...

 @Override
 public PlatformTransactionManager annotationDrivenTransactionManager() {
     return transactionManger();
 }

 @Bean
 public PlatformTransactionManager transactionManger() {
     return new DataSourceTransactionManager(dataSource());
 }

참고로 스프링4.2부터는 스프링 어노테이션인 @Transcational("빈 이름")으로도 구현체를 바꿀 수 있다.

public @interface Transactional {
    @AliasFor("transactionManager")
    String value() default "";

    @AliasFor("value")
    String transactionManager() default "";
    ... 생략
}

이후 @Transcational이 적용된 클래스를 프록시로 바꿔, PlatformTxmanager를 주입하는 것이다.

공식문서에도 나와있지만 PlatformTxManager는 메서드내에서 새로운 스레드를 만들어 시작하는 것은 트랜잭션을 걸어주지 않는다고 한다. (= 그 스레드는 롤백 안됨) 어찌보면 당연한 사실.