diff --git a/27/JiYongKim/transaction_lock.md b/27/JiYongKim/transaction_lock.md
new file mode 100644
index 0000000..1f56cbf
--- /dev/null
+++ b/27/JiYongKim/transaction_lock.md
@@ -0,0 +1,235 @@
+# Transaction Lock
+
+## 목차
+
+1. 경합 ( Race Condition )
+2. 임계 영역 ( Critical Section )
+3. 락 ( Lock )
+4. 블로킹 ( Blocking )
+5. 교착 상태 ( Dead Lock )
+
+
+
+* * *
+
+
+
+## **경합 (경쟁) 상태 (Race Condition)**
+
+정의 : 공유 자원에 대해 여러 트랜잭션이 동시에 접근을 시도할 때, 타이밍이나 순서 등이 결과값에 영향을 줄 수 있는 상태를 말한다.
+
+>⇒ 즉 **두 가지 이상의 트랜잭션이 실행되는 순서를 명확하게 정해지지 않아** 어떤 트랜잭션이 먼저 실행될 지 몰라 그 결과 데이터의 일관성을 유지할 수 없는 상태
+
+
+
+**경합 조건이 일어나는 조건!**
+
+- 두 개 이상의 트랜잭션이 공통된 데이터에 접근하여 읽기/쓰기 작업이 일어날때!
+
+
+
+## 임계 영역 ( Critical Section )
+
+**임계영역(Critical Section)**
+
+정의 : 프로세스간 공유 자원 접근 하는데 있어 문제가 발생하지 않도록 한번에 하나의 프로세스만 접근 할 수 있도록 보장 해주어야 하는 영역을 말한다.
+
+
+
+**임계영역을 해결하기 위한 3가지 조건**
+
+>⇒ 임계 영역을 문제를 해결 하기 위해 3가지 조건을 충족하여야 한다.
+
+- 상호 배재 ( Mutual Exclusion )
+ - 하나의 프로세스가 임계영역에 접근 하였을 경우 다른 프로세스는 접근할 수 없어야 한다.
+
+
+
+- 진행 ( Progress )
+ - 현재 이용하지 않는 임계영역에 접근하는 프로세스가 여러개라면 어떤 프로세스가 들어가야 할지 결정해주어야 한다.
+
+
+
+- 한정 대기 ( Bounded Waiting )
+ - 다른 프로세스의 기아(Starvation)현상을 방지하기 위해 임계영역에 들어간 프로세스는 다음 임계영역에 들어갈 때 제한을 두어야 한다.
+
+
+
+
+
+**임계 영역 동시 접근 해결 방법**
+
+- Lock
+- Semaphore
+- monitor
+
+ .. 등이 있다.
+
+
+
+
+**[ 락(Lock) ]**
+
+- 로킹(Locking)기법: 트랜잭션들이 동일한 데이터 항목에 대해 임의적인 병행 접근을 하지 못하도록 제어하는 것
+
+
+
+- 트랜잭션 T가 데이터 항목 X에 대해 Read(X) or Write(X)연산을 수행하려면 반드시 lock(X) 연산을 해주어야 함
+
+
+
+- 트랜잭션 T가 실행한 lock(X)에 대해서는 해당 트랜잭션이 종료되기 전에 반드시 unlock(x)연산을 해주어야 함
+
+
+
+- 트랜잭션 T는 다른 트랜잭션에 의해 이미 lock이 걸려 있는 X에 대해 다시 lock(X)를 수행시키지 못한다.
+
+
+
+- 트랜잭션 T가 X에 lock을 걸지 않았다면, unlock(X)를 수행시키지 못한다.
+
+
+
+>즉 여러 개의 트랜잭션들이 하나의 데이터로 동시에 접근하려고 할 때 이를 제어해주는 도구가 바로 Lock이다.
+
+
+
+락(Lock)은
+
+- 트랜잭션이 읽기를 할 때 사용하는 공유락(LS, Shared Lock)
+
+ >⇒ 트랜잭션 T가 데이터 항목 X에 대하여 Shared-Lock을 설정할 경우, 트랜잭션 T는 해당 데이터 항목에 대해서 읽을 수 있지만 기록할 수 없다. 그리고 Read는 서로 영향을 주지 않으므로 다른 트랜잭션도 Shared-Lock이 설정된 X에 대해서 Shared-Lock을 동시에 설정할 수 있다.
+
+
+
+- 읽고 쓰기를 할 때 사용하는 배타락(LX, Exclusive Lock)으로
+
+ >⇒ 트랜잭션 T가 데이터 항목 X에 대하여 Exclusive-Lock을 설정할 경우, 트랜잭션 T는 해당 데이터 항목에 대해서 읽을 수도 있고, 기록할 수도 있다. Write는 영향을 주는 작업이므로 다른 트랜잭션은 Exclusive-Lock을 설정한 데이터 항목 X에 대해서 어떠한 lock도 설정할 수 없다.
+
+
+
+
+## Lock
+
+**Lock이란 트랜잭션 처리의 순차성을 보장하기 위한 방법** 이다. 트랜잭션이란 DB의 나누어지지 않는 최소한의 처리 단위이다.
+
+
+
+## Lock의 종류
+
+**Lock의 종류로는 공유(Shared) Lock과 베타(Exclusive) Lock이 있다. 공유락은 다른 말로 Read Lock이라고 불리며 베타락은 Write Lock이라고도 불린다.**
+
+
+
+### 공유(Shared) Lock
+
+**공유 Lock은 데이터를 읽을 때 사용되어지는 Lock**이다. 이런 **공유 Lock은 공유 Lock 끼리는 동시에 접근이 가능**하다. 즉, 하나의 데이터를 읽는 것은 여러 사용자가 동시에 할 수 있다라는 것 하지만 공유 Lock이 설정된 데이터에 베타 Lock을 사용할 수는 없다.
+
+
+
+### 베타(Exclusive) Lock
+
+**베타 Lock은 데이터를 변경하고자 할 때 사용**되며, 트랜잭션이 완료될 때까지 유지 된다. **베타락은 Lock이 해제될 때까지 다른 트랜잭션(읽기 포함)은 해당 리소스에 접근할 수 없다.** 또한 해당 Lock은 다른 트랜잭션이 수행되고 있는 데이터에 대해서는 접근하여 함께 Lock을 설정할 수 없다.
+
+
+
+## Lock의 설정 범위(Level)
+
+- **데이터베이스**
+ - 데이터베이스 범위의 lock은 전체 데이터베이스를 기준으로 lock 하는 것. 즉, 1개의 세션만이 DB의 데이터에 접근이 가능합니다. 해당 기능은 일반적으로는 사용하지 않는다. **사용하는 때가 있다면 DB의 소프트웨어 버전을 올린다던지 주요한 DB의 업데이트에 사용한다.**
+
+
+
+- 파일
+ - 데이터베이스 파일을 기준으로 lock을 설정 한다. 파일 이란 테이블, row 등과 같은 실제 데이터가 쓰여지는 물리적인 저장소 이다. 해당 범위의 Lock은 잘 사용되지는 않는다.
+
+
+
+- **테이블**
+ - 테이블 수준의 Lock은 테이블을 기준으로 Lock을 설정 한다. 이는 테이블의 모든 행을 업데이트 하는 등의 전체 테이블에 영향을 주는 변경을 수행할 때 유용 즉, **DDL(create, alter, drop 등) 구문과 함께 사용되며 DDL Lock이라고도 한다.**
+
+
+
+- 페이지와 블럭
+ - **파일의 일부인 페이지와 블록을 기준으로 Lock을 설정**한다. 잘 사용되지는 않는다.
+
+
+
+- 컬럼
+ - 컬럼 기준의 Lock은 컬럼을 기준으로 Lock을 설정할 수 있다. 하지만 이 형식은 Lock 설정 및 해제의 리소스가 많이 들기 때문에 일반적으로 사용되지는 않으며 지원하는 DBMS도 많지 않다.
+
+
+
+- **행(Row)**
+ - **행 수준의 Lock은 1개의 행(Row)를 기준으로 Lock 설정을 한다. DML에 대한 Lock으로 가장 일반적으로 사용하는 Lock이다.**
+
+
+
+- 데이터베이스
+- 파일
+- 테이블
+- 컬럼
+- 행
+
+
+
+## 블로킹(Blocking)
+
+**블로킹은 Lock간(베타 - 베타, 베타 - 공유)의 경합이 발생하여 특정 Transaction이 작업을 진행하지 못하고 멈춰선 상태**를 말한다. 위에 설명했듯이 공유락 끼리는 블로킹이 발생하지 않지만 베타락은 블로킹을 발생시킨다. 블로킹을 해소하기 위해서는 이전의 트랜잭션이 완료(커밋 OR 롤백)되어야 한다. 뒤에 들어온 트랜잭션은 이전 트랜잭션이 마무리되어야 이후 진행이 가능하다. 이런 경합은 성능에 좋지 않은 영향을 미친다. 따라서 경합을 최소화 할 필요가 있다.
+
+
+
+
+
+
+blocking
+
+DB를 사용하는 프로그래밍을 진행하면서 몇가지 주의사항
+
+1. 한 트랜잭션의 길이를 너무 길게하는 것은 경합의 확률을 올린다.
+
+
+2. 처음부터 설계할 때 같은 데이터를 갱신하는 트랜잭션이 동시에 수행되지 않도록 해야한다.
+
+
+3. 트랜잭션 격리성 수준을 불필요하게 상향 조정하지 않는다.
+
+
+4. 쿼리를 오랜시간 잡아두지 않도록 적절한 튜닝을 진행한다.
+
+이외에 DBMS에 따라서 lock 대기 시간 등을 설정할 수 있다.
+
+
+
+## 교착상태(DeadLock)
+
+**교착상태는 두 트랜잭션이 각각 Lock을 설정하고 다음 서로의 Lock에 접근하여 값을 얻어오려고 할 때 이미 각각의 트랜잭션에 의해 Lock이 설정되어 있기 때문에 양쪽 트랜잭션 모두 영원히 처리가 되지않게 되는 상태**를 말한다.
+
+
+
+
+
+이미지를 보면, Master 와 Slave 테이블이 있다.
+
+- 트랜잭션 A가 Master 테이블에 2번 Row를 수정했고 Slave 테이블에 2번 Row를 이어서 수정하려고 한다.
+
+- 동시에
+트랜잭션 B는 Slave테이블의 2번 Row를 수정하고 이어서 Master 테이블의 2번 Row를 수정하려고 한다.
+
+- 이 경우 트랜잭션 A는 Master 테이블의 2번 Row에 배타 락을 설정했고
+
+- 트랜잭션 B는 Slave테이블의 2번 Row에 배타 락을 설정하였다.
+
+- 그리고 교차로 트랜잭션 A는 Slave Table의 2번 row의 Lock 설정을 하려고 하고
+
+- 트랜잭션 B는 Master Table의 2번 row에 Lock 설정을 하려고 한다.
+
+- 하지만 이미 각 row들은 서로다른 트랜잭션에 의해서 배타락 설정이 되어있기 때문에 Lock이 해제되기를 서로 기다리게 되고 Lock은 풀리지 않을 서로의 트랜잭션 기다리므로 영원히 이 상태가 풀리지 않게 된다.
+
+
+
+
+
+[ deadlock ]
+
+**그래서 교착상태가 발생하면 DBMS가 둘 중 한 트랜잭션에 에러를 발생시킴으로써 문제를 해결한다. 교착상태가 발생할 가능성을 줄이기 위해서는 접근 순서를 동일하게 하는것이 중요**하다. 즉, 위의 예제라면 프로그래밍을 할 때 Master를 업데이트 한 후 Slave을 업데이트 한다와 같은 규칙을 정해 테이블 접근의 교차가 일어나지 않도록 하는것이 중요하다.
diff --git a/27/JiYongKim/transaction_lock.pptx b/27/JiYongKim/transaction_lock.pptx
new file mode 100644
index 0000000..dfd3765
Binary files /dev/null and b/27/JiYongKim/transaction_lock.pptx differ