네 반갑습니다 오늘은 락을 사용해서 concurrency 컨트롤을 어떻게 구현할 수 있는지를 살펴보도록 하겠습니다 그럼 오늘도 고고싱 자

여기 데이터베이스에 10이라는 값을 가지는 x라는 데이터가 있습니다 이제 x를 20으로 바꿔주는 트랜잭션 1번이 시작을 한다고 했을 때

그러면 이 트랜잭션은 이렇게 x를 20으로 라이트를 해주게 되겠죠 그런데 실제로 이렇게 라이트를 하는

과정은 지금은 쉽게 설명을 하려고 이렇게 간단하게 표시를 한 거지만 사실은 단순히 값 하나 바꾸는 것보다

더 복잡한 과정이에요 라이트를 하게 되면 만약에 인덱스가 걸려 있다면 인덱스에 대한 처리를 해줘야 될 수도

있고요 그리고 이 데이터가 실제로 저장되는 파일에 대해서도 이런저런 처리를 해줘야 될 수도 있어요 그래서 이렇게 라이트를 한다는 게 그냥

값 하나 바꾸는 것처럼 그렇게 단순하지만은 않은 작업인 거죠 그렇기 때문에 만약에 x를 90으로 바꿔주는

트랜잭션 2번이 이렇게 동시에 실행이 된다고 해볼게요 그러면은 같은 데이터에 대해서 이렇게 둘 다 라이트를 동시에 실행을 하는 거니까

어쩌면 이 x에 대한 처리가 깔끔하게 되지 않아서 예상치 못한 결과가 발생할 수도 있습니다 그래서 지금 예제는 이렇게 같은 데이터를

y2 하는 건데 꼭 그게 아니더라도 이렇게 라이트를 하고 있을 때 동시에 같은 데이터에 또 다른 리드나

라이트가 있다면 예상치 못한 동작이 발생할 수 있는 거죠 그러면 이 문제를 어떻게 해결할 수 있냐 바로 락을

써서 해결할 수가 있습니다 이 락은 우리가 운영체제에서 배우는 그 락과 같다고 보시면 돼요 이 락에 대해서

간단하게 설명하면 데이터마다 락이 있어서 그 데이터를 변경하거나 읽으려면 그 락을 취득을 해야 돼요. 만약에 락을 취득하지

못하면 그 락을 취득할 때까지 기다려야 되는 겁니다. 그러면 이 락을 써서 방금 이 두 개의 트랜잭션을

처리를 해보도록 하겠습니다. 자 트랜잭션 1번이 이렇게 먼저 시작을 했다면 지금 이 트랜잭션은 x를

20으로 바꿔주는 트랜잭션이기 때문에 데이터 x에 대해서 라이트 락, 그러니까 쓰기 락을 먼저

획득을 해야 됩니다. 그래서 이렇게 라이트 락을 획득을 했어요. 그런데 이 타이밍에서 트랜잭션 2번이 시작을 한

거예요. 그러면 이 트랜잭션은 x를 90으로 바꿔주는 트랜잭션이기 때문에 얘도 먼저 x에 대해서 이 라이트 락을

획득하려고 시도를 합니다. 하지만 이미 이 x에 대한 라이트 락은 트랜잭션 1번이 쥐고 있기 때문에

그러면 이 트랜잭션 2번은 더 이상 진행하지 못하고 이 락이 풀릴 때까지 기다리게 됩니다. 그러면

트랜잭션 2번은 락이 풀릴 때까지 기다리게 되고 그러니까 블락이 되는 거죠. 그렇게 블락이 되고 트랜잭션

1번은 계속해서 이어서 진행을 합니다. 그래서 얘는 x를 20으로 라이트를 하고요. 그러면 이제 이 값이 이렇게 20으로 바뀌게 되겠죠. 그리고 나서

락을 해제를 합니다. 그러면 이 락을 획득하려고 기다리고 있던 트랜잭션 2번이 이제 이렇게 락을 획득하게

되는 거죠. 그러면 이제 주저 없이 진행을 하면 됩니다. x를 90으로 이렇게 라이트를 해주고요. 그러면 여기가 이제 이렇게 90으로 바뀌게 됩니다. 이제

x에 대한 처리는 끝이 났으니까 락을 해제를 해줘야 되겠죠. 그래야 또 다른 트랜잭션이 x에 대해서 읽기나

쓰기를 하려면 이어서 처리를 할 수 있으니까요. 그래서 이렇게 x에 대해서 언락을 수행을 합니다. 그러면 이 락은

이제 반환이 되는 거죠. 또 다른 예를 하나 살펴보겠습니다. 이번에는 트랜잭션 1번은 똑같아요. x를 20으로

바꿔주는 건데 트랜잭션 2번 x를 읽는 트랜잭션입니다. 이번에도 트랜잭션 1번이 먼저 시작을 했다고

해볼게요. 그러면 쓰기를 할 목적으로 락을 취득을 합니다. 그래서 이렇게 락을 획득을 했구요. 그리고 이 타이밍에

트랜잭션 2번이 시작을 해요. 얘는 x를 읽는 거잖아요. 그러면 x를 읽기 위해서 읽기 위한 목적으로 락을 획득하려고

시도를 해요 하지만 이 경우에도 이미 트랜잭션 1번이 x에 대해서 쓰기를 할 목적으로 이렇게 락을 이미 취득을

한 상태였기 때문에 그러면 트랜잭션 2번은 이 락을 취득하기 위해서 계속 기다리게 됩니다 더 이상 진행을 하지

못하는 거예요 하지만 트랜잭션 1번은 계속 진행을 할 수 있겠죠 그래서 이렇게 x는 20으로 라이트를

해주고요 그러면 x값은 이렇게 업데이트가 되겠죠 그리고 나서 이제 x에 대한 처리가 끝이 났으니까 이렇게 x에 대해서 언락을 해주는

겁니다 그러면 이제 이 락을 해제가 되고 이 락이 해제되기를 기다리고 있었던 트랜잭션 2번이 x에 대해서

읽기 목적으로 사용될 락을 이렇게 취득할 수 있게 되는 거죠 그리고 나서 트랜잭션 2번도  자신의 진행을

하게 됩니다. 그래서 x의 값이 20이라고 읽게 되고요. 이어서 x에 대한 락을 이렇게 판단을 하게 됩니다. 자, 그러면 여기까지의 내용을 정리를 하면 먼저

우리는 라이트 락이라는 것을 배웠어요. 이 라이트 락은 또 다른 말로는 익스클루시브 락이라고도 합니다. 얘는

자, 이름은 라이트 락이지만 사실은 라이트 용도뿐만 아니라 리드를 할 때도 사용을 할 수 있어요. 핵심은 익스클루시브라는 겁니다. 무슨

말이냐면 라이트 락을 획득을 하게 되면 다른 트랜잭션이 같은 데이터에 대해서 동시에 리드나 라이트 하는 것을

허용하지 않게 되는 거죠. 자, 다시 강조하고 싶은 것은 라이트 락이라고 해서 무조건 라이트 할 때만 사용해야 되는 것은 아닌

거예요. 이 라이트 락은 익스클루시브의 형태로 쓸 때 사용되는 거라서 일단 라이트 락을 획득한 뒤에는 라이트로

쓸 수도 있고 리드로 쓸 수도 있고 리드 라이트를 둘 다 할 수도 있고 그것은 자유롭게 쓸 수 있는 겁니다

대신에 익스클루시브한 형태, 그러니까 다른 트랜잭션은 같은 데이터에 동시에 리드나 라이트를 할 수 없다. 그렇게

이해를 하시면 되고요. 그 다음에 리드 락이 있습니다. 쉐어드 락이라고도 하는데요. 얘는 락을 획득하는 이유가 읽기를 위한 목적으로

획득을 하는 거예요. 그렇기 때문에 얘는 리드할 때 사용을 해야 됩니다. 라이트 할 때는 이 리드 락이 되지 않고요. 리드할 때 사용이 되는 거예요.

그래서 얘는 특징이 뭐냐면 또 다른 이름이 쉐어드 락이라고 했잖아요. 이게 무슨 의미냐면 다른 트랜잭션이 같은

데이터에 대해서 동시에 리드하는 것은 허용한다라는 의미인 거예요. 이 부분은 직관적으로 생각해 봐도 당연한

얘기겠죠 읽기를 하는 것은 데이터를 바꾸는 것은 아니기 때문에 같은 데이터에 동시에 아무리 여러 개가 읽어도

그것은 전혀 문제될 것이 없으니까 리드락 같은 경우에는 또 다른 트랜잭션이 같은 데이터에 대해서 리드를 하려고 할 때는 그것은 허용을

하는 겁니다 대신에 이미 내가 리드락을 가지고 읽고 있는데 같은 데이터에 대해서 다른 트랜잭션이 라이트를 하려고 한다 즉 쓰기를

하려고 한다면 이때는 이 리드를 보호를 해야 되기 때문에 그때는 이 리드락이 안전하게 데이터를 읽을 수 있도록

보호하는 역할을 하는 거죠 자 그러면 이 라이트락과 리드락을 잘 이해하기 위해서 두 가지 예제를 추가로 살펴볼게요 자 바로 앞에

예제입니다 트랜잭션 1번은 x를 20으로 바꾸는 거고요 트랜잭션 2번은 x를 읽는 거예요

그런데 이번에는 트랜잭션 2번이 먼저 시작을 한 겁니다. 그러면 얘는 x를 읽기 위해서 먼저

락을 획득을 해야 되는데 리드 하기 위한 목적으로 락을 획득을 하는 거예요. 자, 그래서 이렇게 락을

획득을 했고요. 이어서 이 타이밍에 트랜잭션 1번이 시작을 했어요. 얘는 x를 20으로 바꾸는 트랜잭션이기

때문에 x에 대해서 쓰기를 위한 목적으로 락을 획득을 하려고 시도를 합니다. 하지만 이미 트랜잭션 2번이 x에

대해서 리드 목적의 락을 획득을 한 상태이기 때문에 트랜잭션 1번은 이 right를 획득할 수가 없구요. 대신에 이 락이 해제가 될

때까지 기다려야 됩니다. 그래서 트랜잭션 1번은 더 이상 진행하지 못하고 블락이 되는 거죠. 대신에 트랜잭션

2번은 주주적 진행을 합니다. 그래서 이렇게 x에 대해서 10이라는 값을 읽은 뒤에 x에 대한 락을 이렇게 반환을 하는 거죠. 그러면 이렇게

반환을 하게 되면 여기서부터 락을 획득하려고 기다리고 있던 트랜잭션 1번이 이제 쓰기 락을 이렇게 획득하게

되고요. 그러면 이어서 진행을 하면 되니까 이렇게 x를 20으로 쓴 뒤에 그 락을 반환하게 됩니다. 그래서 이렇게 락이 해제가 되는 거죠. 이해가

되시나요? 그래서 지금 이 예제는 트랜잭션 2번이 x를 먼저 읽게 됐을 때 리드 락을 획득을 하게 되면서 그

리드 락을 통해 다른 트랜잭션이 같은 데이터에 대해서 라이트를 하려고 할 때 읽기를 이렇게 보호하는 역할을 하게 됐다. 이것을 확인해 볼 수 있는

예제였구요. 또 다른 예제를 하나 살펴보겠습니다. 이번에는 1번 트랜잭션도 x를 읽는 거고 2번

트랜잭션도 x를 잃는 거예요. 자, 만약에 2번 트랜잭션이 먼저 시작을 했다면 x를 읽기 위해서

읽기 목적의 락을 획득하려고 하겠죠. 그래서 이렇게 락을 획득을 했습니다. 자, 이 타이밍에 트랜잭션 1번도 시작을

했어요. 그러면 얘도 마찬가지로 x를 읽어야 하기 때문에 x에 대해서 읽기 목적으로 락을 획득하려고 해요. 자

그런데 아까 앞에서 살펴봤던 것처럼 리드 락 같은 경우에는 다른 트랜잭션이 같은 데이터에 대해서

읽으려고 한다면 그때는 그것을 허용한다고 했잖아요. 그래서 이 트랜잭션 1번도 이렇게 리드 락을 획득할 수

있습니다. 그러면 이렇게 둘 다 리드 락을 획득을 했으니까 둘 다 이렇게 데이터를 읽을 수가 있어요. 서로가 서로에게 영향을 주지

않고 둘 다 이렇게 읽을 수 있기 때문에 이렇게 동시에 같은 라인으로 표현을 해봤습니다. 그리고 나서 둘 다

이렇게 언락을 하게 되면 이렇게 읽기를 하기 반환이 되는 거예요. 이해가 되시죠? 자, 그래서 지금까지의

내용을 정리를 해보면 서로에 대해서 호환성이 있어요. 그래서 어떤 트랜잭션의 리드락을 쥐고 있는데

같은 데이터에 대해서 또 다른 트랜잭션이 리드락을 획득하려고 한다면 그때는 허용이 됩니다. 하지만 그 외에

모든 경우 예를 들어서 어떤 트랜잭션이 라이트락을 쥐고 있는데 같은 데이터에 대해서 리드락을 주려고

한다면 얘는 그게 허용되지 않고 이 라이트 락이 해제될 때까지 기다려야 됩니다. 반대로 이미 어떤 트랜잭션이

리드락을 쥐고 있는데 같은 데이터에 대해서 다른 트랜잭션이 라이트락을 주려고 한다면 이 또한 허용되지

않고요. 이 리드락이 해제될 때까지 기다려야 됩니다. 그러니까 블락이 되는 거죠. 마찬가지로 어떤 트랜잭션이

라이트락을 쥐고 있는데 같은 데이터에 대해서 다른 트랜잭션이 라이트락을 주려고 한다면 얘도 또한 허용되지

않고 먼저 쥐고 있던 라이트락이 해제될 때까지 기다려야 됩니다. 그래서 이런 호환성이 있다라는 것을 잘

기억을 해주시면 좋을 것 같고요. 자, 그러면 이제 우리가 락에 대해서 살펴봤으니까 실제로 락을 통해서

컨커런시 컨트롤이 어떻게 구현될 수 있는지, 그러니까 어떻게 하면 시리얼라이저빌리티를 보장할 수

있는지 트랜잭션의 아이솔레이션이 보장될 수 있는지 이런 것을 살펴보도록 하겠습니다 자 락이 있다고

해서 락을 사용하는 것만으로는 트랜잭션의 시리얼라이저빌리티를 보장할 수가 없거든요 그래서 락을 사용했음에도 이상한 현상이

발생할 수 있는 그 예를 하나 살펴보도록 하겠습니다 자 데이터베이스에 이렇게 xy가 있습니다 x는 100이라는 값을 가지고 있고

y는 200이라는 값을 가지고 있어요 이 상황에서 두 개의 트랜잭션이 실행을 할 건데요 1번 트랜잭션은

x와 y의 합을 구해서 x에 저장을 하는 거고요 2번 트랜잭션은 x와 y의 합을 구해서 y에 저장을 하는 트랜잭션입니다 자 그러면

각각의 트랜잭션을 어떻게 실행할 수 있냐 그것부터 살펴볼게요 트랜잭션 1번은 x와 y의 합을

구해서 x에 저장을 하는 거니까 그러면 일단은 y는 읽기만 하면 되는 거잖아요 그래서 y를 읽기 위해서 이렇게 리드 목적으로 락을 획득을

해요 그리고 나서 y의 값을 읽습니다 그리고 y를 읽는 것은 끝났으니까 이 y를 언락해요 그리고 이제 뭘 해야 되죠 x의 어떤 값이 있는지

읽고 그리고 나서 x와 y의 합을 x에 써야 되는 거잖아요 그러면 x를 읽고 나서 결국 x에 써야 되는 거니까 한 번에

처리하기 위해서 이 x에 대해서 쓰기 목적으로 락을 획득을 합니다 그래서 이렇게 락을 획득한 뒤에 x에 대해서

값을 읽어요 그리고 나서 그 x와 y의 값을 더해서 이렇게 x에 쓰는 작업을 하고요 끝으로 그 x에 대한 락을 해제를 하는 겁니다 이게 일반

트랜잭션이 동작하는 방식이에요 그러면 이번에는 트랜잭션 2번이 어떻게 동작하는지를 살펴보겠습니다

얘는 x와 y의 합을 구해서 y에 저장을 하는 거잖아요 그러면 x는 읽기만 하면 되는 거니까 일단 x에 대해서 읽기 목적으로 락을 획득을

합니다 그리고 x를 읽어요 그 뒤에 x에 대해서 언락을 하고요 그리고 나서 얘도 마찬가지로 y를 읽고 난 뒤에 결국 y에 써야 되니까 그러면

쓰기 목적으로 이렇게 락을 획득을 합니다 그리고 나서 y를 읽은 뒤에 x와 y의 합을 구해서 y에 써요

그리고 y에 대해서 쥐고 있던 락을 해제를 합니다 이해가 되시죠 자 그러면 이렇게 두 개의 트랜잭션에

BJ.45 LOCK을 활용한 concurrency control 기법을 배워봅니다. 2PL(two-phase locking)도 같이 설명드려요~

8년차 백엔드 개발자가 배워서 남주려고 만든 채널이에요

알기 쉽게 설명합니다

함께 성장했으면 좋겠어요 :)


#컴공맛집 #백엔드전문채널


쉬운코드

Concurrency Control using Locks: Basic Concepts

Introduction of a database scenario with data 'x' and transactions modifying it.

Explanation of the complexity of write operations beyond simple value changes.

Problem of concurrent transactions writing to the same data, leading to unexpected results.

Introduction of locks as a solution to concurrency control problems.

Explanation of lock mechanism: acquiring locks before reading or writing data.

Write Locks (Exclusive Locks) and Read Locks (Shared Locks)

Transaction 1 acquires a write lock on 'x' before modification.

Transaction 2 attempts to acquire a write lock on 'x', but it's blocked.

Scenario where Transaction 1 writes and Transaction 2 reads 'x'.

Summary of write locks (exclusive) and read locks (shared).

Explanation of read locks and their behavior with concurrent reads and writes.

Implementing Concurrency Control with Locks and the Two-Phase Locking (2PL) Protocol

Discussion on how locks ensure serializability and transaction isolation.

Example scenario with transactions involving 'x' and 'y'.

Demonstration of a potential concurrency issue leading to incorrect results.

Solution: Reordering lock acquisition to resolve the concurrency issue.

Two-Phase Locking (2PL) Protocol and its Variations

Explanation of the 2PL protocol: all locking operations before the first unlock operation.

Discussion on potential deadlocks in 2PL.

Introduction of different types of 2PL protocols.

Conservative 2PL: acquiring all locks before starting the transaction.

Strict 2PL (S2PL): releasing locks only at commit or rollback.

Strong 2PL (SS2PL): releasing all locks (read and write) at commit or rollback.

Limitations of 2PL and Introduction to Multi-Version Concurrency Control (MVCC)

Discussion on performance limitations of 2PL due to blocking.

Introduction of MVCC as a solution to improve concurrency.

Many modern RDBMS use a combination of locks and MVCC.

Modern RDBMS use MVCC to enhance performance.