본문 바로가기

SpringBoot

좋아요 구현, Exclusive Lock에 대해서 알아보자.

오늘 포스팅에서 체험해 볼 내용은 'Exclusive Lock (X-Lock, 배타적 잠금)' 에 관한 내용입니다

 

좋아요 기능을 구현하기에 앞서, Lock에 대해서 좀 더 깊이 공부할 필요가 있다고 느꼈고, 직접 가상의 테이블을 생성해서 테스트해보기로 했습니다.

 

그 과정을 공유해보도록 하겠습니다.

 

테스트 환경은 Docker, Mysql로 하였습니다.

 


Docker에서 Mysql을 pull해주시고, DB를 생성해주세요.

저는 joney-board-mysql 이라는 이름으로 db를 띄웟습니다.


 

docker exec -it [컨테이너 이름 또는 번호] bash

mysql -u root -p

비밀번호 입력


테스트를 위해 스키마 생성 후, 테이블을 하나 생성해줄게요.

create database test_db; 

use test_db;


create table lock_test(id bigint not null primary key, content varchar(100) not null);

 

test_db라는 스키마를 생성했고, lock_test라는 스키마도 생성했습니다.


여기에 임의로 id = 1234 그리고 content는 test라는 데이터를 insert 해볼게요.

insert into lock_test values(1234,'test');

그 후, start transaction; 이라는 명령어로 트랜젝션을 실행시킵니다


 update lock_test set content='test2' where id=1234;

update문으로 id가 1234인 데이터의 content를 test2로 변경해봅시다.


 

select*from performance_schema.data_locks;

명령어를 통해 lock이 잘 걸렸는지 확인해봅시다

사진에서 보이는 것처럼, ENGINE_TRANSACTION_ID는 1911이며, X라는 표시가 있는걸로 봐선 잘 걸려있는걸 확인 할 수 있네요.


 

또다른 터미널을 열어서 같은 방법으로 DB에 접속해줍시다.

 

 

select * from lock_test where_id=1234;

아직 1번 터미널에서 commit을 안한 상태이기 때문에 여전히 content가 test인 걸 확인할 수 있네요.

그럼 2번 터미널에서 update를 한번 해볼까요?


 

 update lock_test set content='test2' where id=1234;

사진에서 보는것처럼 바로 update가 안되고, timeout 이 뜨네요.


 

마찬가지로 start transaction; 명령어로 트랜젝션을 시작하고 다시 한번 update명령어를 날려봅시다.

그 후, 곧바로 1번 터미널로 와서 commit;명령어를 적어주세요.


1번 터미널에서 commit; 명령어를 입력한 순간, 2번 터미널에서 update문이 실행되는 걸 확인할 수 있었네요


 

터미널 2에서 select * from performance_schema.data_locks; 을 통해 조회를 해보면 ENGINE_TRANSACTION_ID가 1913으로 변경된 걸 확인할 수 있구요.

 

commit; 을 한 후, 다시 한 번 조회를 해보면,

 이렇게 잠겨있던 lock이 사라진 것을 확인 할 수 있습니다.


글로 적다보니 과정이 살짝 복잡하게 느껴질 수 있는데, 해보시면 엄청 간단한 테스트 였다는걸 알게 되실거예요.

 

요즘 AI가 많이 발달하며, 바이브 코딩을 많이들 하시던데, 어떻게 트랜젝션이 작동하는지 직접 눈으로 확인할 수 있어서 빠른 이해가 가능했어요. 아무래도 이런 동작원리나 개념들에 대해 좀 더 깊게 학습할 필요를 느끼는 요즘입니다~