@Transactional 정리가 필요해

사실이 아니라 공부한 내용과 생각을 정리한 글입니다. 언제든 가르침을 주신다면 감사하겠습니다.

 

Spring에서 DB 접근 기술은 많이 추상화되어 있다.

 

가장 기본적으로 JDBC가 있고 이를 조금 더 편하게 사용하기 위한 Mybatis, JPA 등이 있다.

 

트랜잭션은 이러한 JDBC, Mybatis, JPA에서 본래 가지고 있던 부분은 아니다. 데이터베이스 자체에서 출발한 부분이다.

 

그래서 그런지, 개발을 하면서 데이터베이스 수준, JDBC 수준, Mybatis 수준, JPA 수준에서 트랜잭션이 어떠한 의미를 갖는지 혼란이 온다.

 

따라서 이 글을 시작으로 앞으로 관련 내용을 학습할 때마다 정리하려고 한다.

 

----------------------------------------------------------------------------

 

1.  데이터베이스 수준 트랜잭션

과거, 별도의 github에 정리해 둔 내용이 있다.

https://github.com/rnjstjdgh/MyPublicStudy/issues/1#issue-924469559

DB 공부 · Issue #1 · rnjstjdgh/MyPublicStudy

 

 

DBMS는 데이터의 처리 및 관리를 위한 복잡한 내부 구조를 숨기고, sql이라는 문법만을 제공한다.

사용자는 sql을 사용해 DBMS에게 데이터 처리를 요청한다.

다시 말하면, 사용자가 DBMS을 제어하는 방법은 sql 뿐이다.(일부 DB설정을 조정하여 DBMS를 제어할 수도 있다.)

여기서, 사용자에는 JDBC도 포함된다. 

따라서, JDBC 또한 DB 작업을 위해 내부적으로 sql을 사용할 수밖에 없다.

 

DB수준의 트랜잭션이란, 

• 사용자가 sql을 통해 원하는 트랜잭션 작업을 요청하면, 그에 맞게 처리하기 위해 DBMS가 사용하는 개념과 기술
• 내부적으로 페이지 버퍼, lock 메커니즘, log 메커니즘을 통해 구현됨

 

2.  JDBC, Spring 수준 트랜잭션

정리가 잘 된 링크가 있다.

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

Transaction 동작 원리, JDBC 기본에 충실한 과정(JPA, Hibernate, Spring's @Transactional)

 

JDBC 수준의 트랜잭션이란,

• JDBC 수준의 트랜잭션은 역시 내부적으로는 sql을 통해 이루어진다.
• 비즈니스 로직을 구현하는 개발자 입장에서 트랜잭션 작업을 위한 sql을 직접 구성하는 것을 대신해 준다.
• 즉, 개발자는 직접 트랜잭션을 위한 sql을 작성하지 않고 JDBC에서 제공하는 commit, rollback,setAutoCommit 등의 api를 사용하면 된다.

Spring 수준의 트랜잭션이란,

• JDBC api를 개발자가 직접 사용하는 것이 아니라 스프링의 @Transactional 만 사용하면 되도록 추상화했다.

 

3.   JPA 수준 트랜잭션(영속성 컨텍스트)

JPA는 사실상 트랜잭션을 직접적으로 관리하지 않는 것 같다. 트랜잭션과 관련한 대부분 기능은 Spring에게 의존한다.

JPA가 관리하는 것은 트랜잭션이 아니라 영속성 컨텍스트 이다. 영속성 컨텍스트는 데이터베이스와 Spring 에플리케이션 사이의 중간 계층이다.

Spring 수준의 트랜잭션의 생명 주기와 JPA가 관리하는 영속성 컨텍스트의 생명 주기를 맞춤으로써 트랜잭션 단위로 JPA 메커니즘이 동작하도록 한다.

 

데이터베이스 작업은 크게 데이터를 조회하는 작업과 수정하는 작업으로 구분할 수 있다.(수정에는 생성, 수정, 삭제가 포함된다.)

영속성 컨텍스트에는 1차 캐시와 쓰기 지연 SQL 저장소가 존재한다.

1차 캐시는 데이터베이스에서 조회된 자바 객체를 캐싱하는 역할을 한다. 더티 체킹 기능이 포함되어 있어서 클린한 객체에 대한 반복적인 조회 sql이 발생하는 경우 캐싱된 데이터를 제공하여 sql이 데이터베이스에 날라가지 않도록 한다.

쓰기 지연 SQL 저장소에는 한 트랜잭션 내에서 발생한 데이터베이스 수정 쿼리들이 쌓인다. 이 쿼리들은 메소드 호출 시점에 바로 데이터베이스로 날라가지 않고 쓰기 지연 SQL 저장소에 저장되어 있다가 트랜잭션이 커밋되는 시점에 데이터베이스로 날아간다. 

이때 1차 캐시의 더티 체킹을 활용해 실제 수정된 객체에 대해서만 수정 SQL을 보낸다.