트랜잭션

 

📑 이전 글: [Jdbc] 커넥션 풀링과 DataSource 인터페이스

 

✅ 트랜잭션 개념

데이터베이스는 트랜잭션을 지원한다.

파일 시스템 대신 데이터베이스를 사용하는 가장 큰 이유 중 하나이기도 하다.

 

트랜잭션이란, 하나의 작업을 안전하게 처리하도록 보장해주는 것이다.

트랜잭션에서 모든 작업이 성공해서 DB에 정상 반영되는 것을 Commit이라고 한다.

트랜잭션에서 작업 중 하나라도 실패해서 트랜잭션 시작 전 상태로 되돌리는 것을 Rollback이라고 한다.

 

📌 트랜잭션 ACID

- 트랜잭션은 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)을 모두 보장해야 한다.

 

🐥 원자성 (Atomicity)

- 트랜잭션 안에서 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공하거나, 모두 실패해야 한다.

 

🐥 일관성 (Consistency)

- 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다.

- 예를 들어 데이터베이스에서 정한 무결성 제약 조건을 항상 만족해야 한다.

 

🐥 격리성 (Ioslation)

- 동시에 실행되는 서로 다른 트랜잭션들이 서로에게 영향을 미치지 않도록 격리해야 한다.

- 격리성은 동시성과 관련된 성능 이슈(트랜잭션 간 격리성을 완벽히 보장하려고 하면 동시 처리 성능이 나빠짐)를 발생시키기 때문에,

  트랜잭션 격리 수준을 선택하여 설정할 수 있다.

📌 트랜잭션 격리 수준 (Isolation level)
- READ UNCOMMITED (커밋되지 않은 읽기)
- READ COMMITED (커밋된 읽기)
- REPEATABLE READ (반복 가능한 읽기)
- SERIALIZABLE (직렬화 가능)

 

🐥 지속성 (Durability)

- 트랜잭션 도중 장애가 발생하더라도 그 결과가 항상 지속되어야 한다.

- 트랜잭션 도중 시스템에 문제가 생기더라도 데이터베이스 로그 등을 확인해서 트랜잭션 성공 내용을 복구해야 한다.

  (부분적으로 수행되었다면 롤백)

- 쉽게 말하면, 정상적으로 완료되었거나 부분완료된 데이터는 DBMS가 책임지고 데이터베이스에 기록해야 한다.

 

 

✅ 트랜잭션 실습 (눈으로 확인)

 

데이터베이스는 하나의 커넥션당 하나의 DB세션이 생긴다.

트랜잭션 도중 변경된 데이터는 DB세션에 임시저장되고, 트랜잭션이 끝나면 커밋 또는 롤백된다.

커밋되기 전 DB 세션에 임시 저장된 데이터는 다른 DB세션에서는 확인할 수 없다.

 

눈으로 확인해보기 위해서 로컬 h2 database를 실행시키고,

두 개의 db 클라이언트로 접속해보았다. (JSESSIONID가 서로 다르다)

 

왼쪽을 세션1, 오른쪽을 세션2라고 하겠다.

테이블은 미리 생성해두었다.

 

📌 수동 커밋 모드 설정하기

 

기본적으로는 자동 커밋 모드로 설정되어 있기 때문에

쿼리 하나를 실행하면 자동으로 commit; 명령어도 함께 실행된다.

 

따라서 하나의 트랜잭션에서 여러 개의 쿼리를 처리하려면 수동 커밋 모드로 설정해야한다.

set autocommit true; // 자동 커밋 모드 설정
set autocommit false; // 수동 커밋 모드 설정

 

 

📌 커밋 전 임시 데이터는 다른 세션에서 확인할 수 없다!

 

세션1에서 insert문을 실행한 뒤, 세션1에서 select해보면 새로 추가한 멤버를 확인할 수 있다.

그러나 세션2에서는 세션1에 임시저장된 데이터를 확인할 수 없다.

 

📌 커밋을 하면, 다른 DB세션에서 보인다!

세션1에서 커밋을 했더니, 세션2에서도 해당 데이터를 볼 수 있다.

 

 

📌 이번에는 세션2에서 멤버 정보를 수정해보았다.

(autocommit 설정은 DB세션마다 따로 설정되는 것 같다.

그래서 세션2에서도 autocommit 속성을 false로 설정해주어야 하는 것을 확인했다)

세션1에서는 세션2에 임시 저장된 데이터를 확인할 수 없다.

 

📌 세션2에서 롤백을 하면, 변경사항이 원상복구된다.

당연히 세션1에서도 원상복구된 데이터를 읽을 수 있다.

 

✅ 데이터베이스 Lock

세션1에서 트랜잭션을 시작하고 데이터를 수정하는 동안

세션2에서도 같은 데이터를 수정하게 되면,

트랜잭션의 원자성이 깨지는 문제가 발생할 것이다.

 

데이터베이스는 이러한 문제를 해결하기 위해 Lock 이라는 개념을 제공한다.

 

특정 세션에서 특정 데이터(row)를 수정하기 위해서는 락을 획득해야한다.

동시에 다른 세션에서 동일한 데이터를 수정하려고 하면 락을 획득하지 못해 대기하게 된다.

락을 가지고 있는 세션이 commit 또는 rollback을 하게 되면 락을 반납하고, 다른 세션이 락을 획득할 수 있게 된다.

 

📌 눈으로 확인해보기

우선 실습을 위해 테이블에 2개의 데이터를 추가하였다.

세션1에서 멤버 asdf의 돈을 100으로 변경하였다. 이때 세션1은 pk가 asdf인 데이터에 대해 락을 획득하게 된다.

동시에 세션2에서 멤버 qwer과 멤버 asdf의 돈을 0으로 변경하려고 시도한다.

세션2는 멤버 qwer에 대해서는 락을 획득하여 멤버 qwer 데이터를 수정할 수 있다.

그러나 멤버 asdf의 경우 세션1이 락을 가지고 있기 때문에 세션2에서 락 획득에 실패하고, 락을 획득할 때까지 대기하게 된다.

 

나같은 경우 set lock_timeout 100; 명령어를 통해 lock 획득을 위해 100millis만큼만 대기하고, 타임아웃이 발생하면 쿼리 실행을 취소하도록 설정해두었다.

 

📌 세션1에서 커밋을 하면 락을 반납한다.

 

세션2에서 다시 멤버 asdf 데이터를 변경시도하면,

락 획득에 성공하여 변경도 성공하게 된다.

 

 

참고로, select for update 구문을 사용하면

특정 세션에서 select하는 동안에도 해당 데이터에 대한 락을 획득하게 된다.

따라서 락을 획득한 세션의 트랜잭션이 끝나지 않은 동안에는

다른 세션에서 해당 데이터를 수정할 수 없게 된다.

 

 

📑 다음 글 :[jdbc] 트랜잭션 관리 (feat. 스프링 프레임워크)