Transaction (작성 중)

격리 명령어 (ISOLATION)

https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html

-- 세션 확인
SHOW FULL processlist;

-- 격리 레벨 설정
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- 현재 레벨 확인
SHOW VARIABLES WHERE VARIABLE_NAME like '%transaction_isolation%';

lock 조회

8 버전 이전

# LOCK을 걸고 있는 프로세스 정보
select * from information_schema.INNODB_TRX;

# 현재 LOCK이 걸려 대기중인 정보
# select * from information_schema.INNODB_LOCK_WAITS;
select * from performance_schema.data_lock_waits;

# LOCK을 건 정보
# select * from  information_schema.INNODB_LOCKS;
select A.LOCK_MODE, A.* from performance_schema.data_locks A;
show open tables where In_Use > 0 ;

8 버전 이후
https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html

select * from performance_schema.data_locks;
select * from performance_schema.metadata_locks;
select * from performance_schema.data_lock_waits;
select * from performance_schema.table_lock_waits_summary_by_table;

Lock 획득

https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html

Locking Reads

-- 읽기 락
select * from item_order where item_id = 2 for share
-- 쓰기 락
select * from item_order where item_id = 2 for update

for share vs for update

share, update 는 다른 트랜잭션 A, B 에서 select 로 조회를 할 수 있는지에 차이점이 있다.
(일반적인 select 이 아닌 select for share, select for update)

• share : select 를 제외한 명령어(insert, update, delete) 에 락에 걸린다.
• update : select, insert, update, delete

❓for share 를 언제 사용할까?
현재 조회된 데이터의 무결성을 유지할 수 있다. (물론 트랜잭션 범위 안에서)
🔥 IMO) 예를 들면 order 를 조회하고 업데이트를 할 때는 for update 를 사용해야 한다.
하지만 order 를 조회하여 다른 테이블의 업데이트로 사용된다면 order의 select 락 은 필요하지 않다.
(update 할 때 select 에 락을 거는 이유를 생각해 보자. (동시성 이슈))

❓❓그러면 for update 를 사용하면 되지 않을까?
물로 for share 대신에 사용해도 상관이 없다. 당연하지만 select 까지 락이 걸리기 때문에 보다 더 성능이 좋지 않다.

name lock 획득

-- 락 획득
SELECT GET_LOCK('jade-1', 10);
-- jade-1 이라는 문자열로 잠금을 획득하며
-- 이미 잠금이 있다면 10초간 대기하고 락 확득을 포기.

-- 락 상태 조회
SELECT IS_FREE_LOCK('jade-1');
-- 문자열 'jade-1' 에 대해서 획득 가능한지를 확인 합니다.
-- 반환 값: 1 사용 가능한, 0 사용이 불가능
    
SELECT IS_USED_LOCK('jade-1');
-- 문자열 jade-1 이 잠금이 설정되어 있는지 확인합니다.
-- 반환 값: 사용 중이면 잠금을 보유한 세션 식별자


-- 잠금해제 명령어
SELECT RELEASE_LOCK('jade-1');
-- 반환 값: 1 정상 해제
select RELEASE_ALL_LOCKS();
-- 반환 값: 해제한 Lock 의 수 (0 이면 없다는 뜻)


SELECT CONNECTION_ID();
-- 반환 값: 현재 세션(연결 아이디) 식별자

-- 세션 조회 명령어
show full processlist;

transaction

-- 오토커밋 유무 확인 및 세팅
SELECT @@AUTOCOMMIT;
-- Auto Commit 켜기
SET AUTOCOMMIT = 1;
-- Auto Commit 끄기
SET AUTOCOMMIT = 0;


START TRANSACTION;
-- Upudate Insert Delete Select
COMMIT;
ROLLBACK;

ACID

Atomicity (원자성)

• ALL or Nothing
• transaction 은 논리적으로 쪼개질 수 없는 작업 단위.

Consistency (일관성)

• transaction 은 DB 상태를 consistent 상태에서 또 다른 consistent 상태로 바꿔줘야 한다.
• 일관성(constraints, trigger 등...) 이 깨지는 경우 rollback.
• transaction 이 DB 에 정의된 rule 을 위반했는지는 DBMS 가 commit 전에 확인하고 알려준다.
• 그 외에 application 관점에서 transaciton 이 consistent 하게 동작하는지는 개발자가 챙겨야 한다. (DB rule 이 아닌 - db transaction 를 벗어나는 규칙 )

Isolation (격리, 분리)

• 여러 transaction 들이 동시에 실행하니 문제가 발생.
• 여러 transaction 들이 동시에 실행될 때도 혼자 실행되는 것 처럼 동작하게 만든다.
• concurrency control 의 주된 목표가 isolation 이다.

Durability (영존성)

• commit 된 transaction 은 DB 에 영구적으로 저장된다.
• "영구적으로 저장한다." 라고 할 때는 일반적으로 비휘발성 메모리(HDD, SSD, ...) 에 저장함을 의미한다.
• 기본적으로 transaction 의 durability 는 dbms 가 보장한다.

---

참고 URL

https://labs.brandi.co.kr//2019/06/19/hansj.html
https://myinfrabox.tistory.com/188
https://jyeonth.tistory.com/32
https://www.youtube.com/watch?v=bLLarZTrebU&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=17

mysql

https://dev.mysql.com/doc/refman/5.7/en/show-processlist.html