eel.log

들어가며최근 아쉽게도 더 이상 진행하지 못하고 종료하게 되었던 프로젝트 코드를 살펴보다가, 문득 @ResponseeBody와 ResponseEntity 둘 중 어떤 것을 사용할지에 대한 의문이 들었다. 차이점개념의 차이ResponseEntity is like @ResponseBody but with status and headers.스프링 공식 문서에서는 ResponseEntity를 @ResponseBody와 대체로 비슷하지만 header나 status를 묶어서 설정할 수 있도록 했다고 설명하고 있다. @GetMapping("/api/category")public ResponseEntity> getCategory() { return ResponseEntity.ok() .body(new ..

들어가며이번에는 대부분의 상용 RDBMS에서 단순히 Lock으로만 동시성 제어를 할 때보다 처리량을 끌어올리기 위해 사용하는  MVCC에 대해 알아보도록 하겠다. 물론 각 RDBMS마다 동작 방식은 다를 수 있으며, 여기서는 MySQL을 기준으로 설명한다. MVCC(Multiversion Concurrency Control)제어 기법에 따른 두 Lock 간 호환성Lock Read LockWrite LockRead LockOXWrite LockXXMVCC Read LockWrite LockRead LockOOWrite LockOXLock으로만 동시성 제어를 했을 때와 비교해 보면 표만 봐도 트랜잭션 처리량이 더 많으리라는 것을 직감할 수 있다. MVCC 이해를 위한 예제예제를 보기 전에 먼저 알아둬야 할 ..

들어가며이번엔 Lock을 활용해 Concurrency Control을 하는 방법에 대해 설명하고자 한다.3편에 앞서 먼저 1편과 2편을 읽어보는 것을 권한다. Lock을 사용하는 이유write 연산과 read 연산을 할 때 여러 트랜잭션이 같은 데이터에 접근하다 보면 이로 인해 예상치 못한 이상현상이 나타날 수 있다. 그래서 lock을 통해 사용하는 데이터를 잠가두는 방식을 활용하는 것이다.다음은 간단한 예시이다.tx1에서 x에 대한 write lock을 획득하고, tx2에서 lock 획득을 시도하지만 이미 tx1에서 lock을 가지고 있기 때문에 lock을 얻기 위해 대기하게 된다. 그러고 나서 tx1이 x를 20으로 바꾼 뒤 lock을 반환한다. 그러면 드디어 tx2에서 write lock을 얻은 뒤..

들어가며이번엔 트랜잭션의 Isolation Level에 대해 정리할 것이다.Isolation Level에 앞서 Isolation이 보장되지 않았을 때 나타날 수 있는 여러 이상현상(Anomaly)들을 먼저 설명한다. AnomalyDirty Read(1)commit되지 않은 데이터를 읽을 때 발생할 수 있는 현상을 의미한다.첫 번째 예시다. tx2에서 y를 70으로 변경했지만 해당 트랜잭션을 commit하지 않고 rollback함으로써 tx1의 결과에도 영향을 미치는 모습이다. Dirty Read(2)이번엔 변화를 발생시킨 트랜잭션이 rollback되지 않았음에도 Dirty Read가 발생하는 예시다. tx1에서 x를 10으로 변경했고 commit되지 않은 상태에서 tx2를 수행했더니 tx2에서의 x + ..

들어가며DB 동시성 제어는 분량이 꽤 많을 것 같아 4편으로 나누어 작성하려고 한다.이번엔 DB 동시성 제어 이해에 필요한 Schedule에 대해 정리할 것이다. ScheduleSchedule이란 여러 트랜잭션들이 동시에 실행될 때 각 트랜잭션에 속한 operation의 실행 순서를 의미한다. Lost Update다음처럼 H와 K의 계좌 잔액을 조회하거나 변경하는 등의 작업을 수행하는 2개의 트랜잭션이 존재한다고 생각해 보자.해당 케이스에서 Tx2가 실행되고 나서 Tx1은 이 사실을 알지 못한 채 H의 계좌 잔액을 220만 원으로 변경한다. 이때 Tx2의 변경사항은 유실되어 버리는데 이를 Lost Update라고 한다. Serial Schedule, Non-Serial Schedule먼저 봤던 케이스를 ..