[TIL] Spring Transaction 1

드디어 금요일이다 !!

주말이 되어도 공부를할 것이기 때문에
월요일까지 순삭당할 것 같다.

하나한 알아갈 수록 좀더 알고 싶은 마성의 기능들…
너무 재밌다. 계속해서 공부하게된다.

오늘은 트랜잭션에 대해 공부해보는 시간이다.
여러번 들어봤고 아직 어떤 의미인지를
정확히 알지못하니 공부해보도록하자

Transaction

Transaction 이란?

트랜잭션은 여러개의 작업들을 하나의 그룹으로
묶어서 처리하는 처리 단위로, 물리적으로는 여러개의 작업이지만
논리적으론 마치 하나의 작업으로 인식해서
전부 성공 or 실패 의 결과로 하나로만 처리되어야하는 의미를 가진다.

예를 들어서, 계좌이체를 한다고 가정하였을 경우
A라는 사람이 B라는 사람에게 계좌이체를 했을때
A는 송금을 했지만 오류로인해 B가 받지 못했을 경우
A의 돈만 빠지고 B는 받지못하는 상황이 생긴다. 이런 경우가 생긴다면
서비스를 하지못할 정도의 큰 일이 나기때문에 송금이라는 작업단위가 있으면
최종적으로 송금완료까지 하나의 트랜잭션으로 봐야하는 것이다.

트랜잭션을 얘기할때는 ACID 원칙을 이용한다.

ACID 원칙

원자성: 트랜잭션 내에서 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공 하거나 모두 실패해야 한다.
일관성: 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다. 예를 들어 데이터베이스에서 정한 무결성 제약 조건을 항상 만족해야 한다.
격리성: 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리한다. 예를 들어 동시에 같은 데이터를 수정하지 못하도록 해야 한다. 격리성은 동시성과 관련된 성능 이슈로 인해 트랜잭션 격리 수준 (Isolation level)을 선택할 수 있다.
지속성: 트랜잭션을 성공적으로 끝내면 그 결과가 항상 기록되어야 한다. 중간에 시스템에 문제가 발생해도 데이터베이스 로그 등을 사용해서 성공한 트랜잭션 내용을 복구해야 한다.

DB로 확인하는 예제

우선 DataBase를 통해 개념을 확인해 볼 수 있다.

간단한 예제를 위해 H2 데이터베이스를 사용했고
쿼리로 각자 memberA, memberB에게 10000원을 넣어두었다.

예를 들어 가정해보자, memberA라는 사람이
2000원을 B에게 준다고 가정하기위해 쿼리를 이용해
왼쪽 세션의 memberA라는 사람의 돈을 2000원 차감 시켰다.
(자동 커밋을 꺼주는 쿼리도 같이 넣었다.)

여기서 중요한점은 왼쪽과 오른쪽은 세션으로 나타낸 것이며
총 두 개의 세션으로 테스트를 하였다.
세션이란 우리가 DB에 접근을 할 떄, 클라이언트와 Connection을 맺게되는데
데이터 베이스 서버는 내부에 세션이란 것을 만들어 해당 커넥션을 통한 모든
요청은 이 세션을 통해서 실행하게 된다.

한 마디로 SQL을 전달 받으면 현재 커넥션에 연결된 세션이 SQL을 실행한다.

이 얘기를 토대로 위를 살펴보자면, 커밋이 이루어 지지 않은 상태이고
왼쪽 세션을 조회 쿼리를 날렸을때는 정상적으로 2000원이 차감되었지만
오른쪽 세션에서는 조회를해도 기존의 10000원이 표시되는 것을 볼 수 있다.

이 말은 즉, 왼쪽 세션이 commit();되지 않아
오른쪽 세션과 다르게 보이는 모습이다.

이 상황에서 왼쪽 세션에 commit(); 명령을 보낸 후
왼쪽 오른쪽 세션을 조회해보면
위와 같이 동일해진 모습을 볼 수 있다.

반대로 왼쪽 세션에서 rollback(); 명령을 보냈을 경우에는
위와 같이 원래상태로 돌아간 모습을 볼 수 있다.

여기서 우리는 알아야할 것이 세션에 따라
서로 상태가 다르게 보이는 문제가 발생한다.
그럼 수많은 사람이 이용하는 클라이언트에서 여러 요청이와
쿼리가 수도 없이 날라왔을 경우에 DB조작에 있어 어려움이 생긴다.

그래서 트랜잭션으로 작업단위를 하나로 묶어
해당 세션이 실행되었을 때 예외발생하지 않고 전부 성공했을 경우
다른 세션이 이용이 가능하도록 구현할 필요가 있다.

DB Lock

위에서 commit();과 rollback();에 대해서 알아보았다.
내가 수행하는 비지니스 로직과 쿼리가 정상적으로 모두 수행되었을때
commit();을 진행하고 도중에 예외가 생기면 rollback();을 해주면된다.

여기서 한가지 생각해보아야할 것이 우리가 commit();을 하기전에
다른 세션에서는 기존의 상태가 보여지게되어진다.

이러한 상태에서 다른세션에서 해당부분을 수정하는 쿼리를 보냈을 경우에는
어떻게 동작이 되어지는가? 하는 의문이생긴다.

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

memberA라는 사람의 돈을 10000으로 셋팅해두고
왼쪽 세션에는 500으로 변경(commit 하지않음), 오른쪽 세션에는 기존과 동일
상태로 둔다음 오른쪽 세션에서 memberA의 돈을 1000으로 바꾸었을 때

어떠한 일이 발생하느냐? 라는게 우리의 초점이다.

결과는 위와 같이 오른쪽 세션에서는 수행할 수 있는 쿼리를 실행한다.
오른쪽 세션을 보면 아래에 실행된 쿼리의 로그를 볼 수 있다.

SET LOCK_TIMEOUT 60000; -> 락 타임아웃을 60초로 설정
set autocommit false; -> 수동커밋으로 변경
이 두가지가 실행 되었고, 궁극적으로 1000원으로 변경하는
update 쿼리문이 실행되지 않은 모습이다.

그 말은 즉, DB에서 Lock이라는 개념을 제공해
변경을 강제로 막아주고 있는 모습이다.

왼쪽 트랜잭션이 실행되어질 때 락을 획득하여
commit();을 하기전까지 다른 세션의 접근을 막고있는 것이다.

하지만 첫번쨰 쿼리로 타임아웃을 설정했기 때문에
해당 트랜잭션은 60초 후에 아래와 같은
알람이 발생하면서 세션이 자동적으로 종료하게된다.

 Timeout trying to lock table {0}; SQL statement:
    update member set money=10000 - 2000 where member_id = 'memberA' [50200-200]
    HYT00/50200

반대로 60초가 지나기 전에 왼쪽 세션에서
commit();하여 락을 반납하였을 경우에는
오른쪽세션에서 락을 획득하여 update 쿼리를 진행한 모습을
위위 사진과 같이 확인해 볼 수 있다.

한 마디로 정리해보자면

세션이 실행되면 락을 획득
해당 락이 반납되기 전까진 다른 세션에서는 수정 불가능
락을 획득한 세션이 commit(); rollback();을 수행해야 락을 반납한다.

이렇게 오늘은 트랜잭션과 DB락에 대해 공부했다.
DB락을 알기전까지는 항상 궁금해해왔다.

동시에 하나의 DB 레코드에 변경할때는 누가 우선권을 가지는거지?라는
물음이 항상있었다. 그 이유는 이전에 PLC 프로그래밍을 하였을 때도
하나의 공정에 동시작업이 물려있으면 우선순위를 처리해줘야하는
로직을 작성해주어야했기 때문이다.

오늘 그 질문에 대한 물음은 어느정도 해결 된 것 같고
최종적으로 궁금한점은 그럼 이 트랜잭션을
Java코드로 어떻게 적용하는게 알맞는 것인지?라는
질문이 생기지만 이후에 학습할 과정에 포함되어있는 것 같으니
공부하면서 다시 깨달아봐야할 것 같다.

오늘 공부는 여기서 끝 !!

오늘의 커피량: ☕️ ☕️
오늘의 점심: 짜장면, 밥