# Isolation

kws60000

에러 상황 Mac OS 환경에서 Mariadb 를 homebrew로 설치했습니다. 이후 spring 에서 작업 시 MySQL 커넥터를 사용해서 DB를 연동했습니다. 잘 사용하다가 파이썬을 설치한 이후로 해당 에러가 발생하고 JDBC DB 연동이 안됐습니다. 에러 원인 transaction_isolation 트랜잭션의 격리수준을 설정하는 변수입니다. 격리수준에 따라 다음처럼 나뉩니다. InnoDB의 기본 격리수준은 REPEATABLE READ 입니다. READ UNCOMMITTED READ COMMITTED REPEATEABLE READ SERIALIZABLE MariaDB 공식 문서를 보니 11.1.1 이전 버전에는 txisolation 을 사용하고 이후 버전에서는 transactionisolation 변수를 사용한다고 했습니다. > To determine the global and session transact

qkrrjsxo

1단계 ![](https://velog.velcdn.com/images/qkrrjsxo/post/4741a745-24f7-4392-97f3-cff222fe2ba6/image.p

kevin_

아래와 같은 시나리오를 구상 해 보도록 하자. > 💡 J가 H에게 20만원을 이체할 때, 동시에 H도 ATM에서 본인 계좌에 30만원을 입금한다면 정상적인 FLOW Transaction1(J가 H에게 20만원을 이체할 때) J의 계좌에 남아있는 잔액을 확인한다. (READ → 100만원) J의 계좌에서 20만원을 인출한 값을 다시 계좌에 적어준다. (WRITE → 80만원) H의 계좌에 남아있는 잔액을 확인한다. (READ → 200만원) H의 계좌에서 20만원을 입급받은 값을 다시 계좌에 적어준다. (WRITE → 220만원) Transaction2(H도 ATM에서 본인 계좌에 30만원을 입금할 때) H의 계좌에 남아있는 잔액을 확인한다. (READ → 220만원) H의 계좌에서 30만원을 입급받은 값을 다시 계좌에 적어준다. (WRITE → 250만원)

alsry922

📒 지난 시간에는 isolation이 지켜지지 않고 트랜잭션이 겹쳐서 실행될 때 일어날 수 있는 이상 현상들에 대해서 알아보았습니다. SQL 표준에서는 dirty read: commit 되지 않은 데이터를 읽었을 때 발생하며, 데이터를 읽은 이후에 이 데이터를 rollback하게 되는 경우 문제가 발생하는 현상 non-repeatable read: 한 트랜잭션에서 같은 데이터를 두 번 읽었는데 두 데이터의 결과가 다른 현상 phantom read: 한 트랜잭션에서 같은 조건으로 데이터를 두 번 읽었는데 두 데이터의 결과가 다른 현상 이렇게 세 가지 이상 현상 개념에 대해서 다루고 이에 대한 isolation level을 아래와 같이 정의했습니다. read uncommited: 세 가지 이상 현상을 다 허용 read commited: dirty read가 발생하는 schedule은 허용 X repeatable read: non-repeatable r

alsry922

📒 저번 포스팅에서는 recoverability에 대해서 알아보았습니다. 요약해봅시다. 여러 트랜잭션이 실행될 때 나올 수 있는 schedule 중 unrecoverable schedule과 recoverable schedule이 있다고 했습니다. unrecoverable schedule은 어떤 트랜잭션이 commit 되지 않은 트랜잭션이 write한 데이터를 읽는 schedule이라고 말했습니다. 이러한 schedule은 rollback할 때 원복하기 힘든 경우가 발생하기 때문에 DBMS에서는 이러한 unrecoverable schedule을 허용하지 말아야 한다고 했습니다. recoverable schedule은 한 트랜잭션이 commit 되지 않은 트랜잭션이 write한 데이터를 읽는 경우 이 트랜잭션이 commit 혹은 rollback하기 전까지 commit하지 않는 schedule입니다. 이러한 recoverable schedule은 roll

alsry922

📒 지난 포스팅에서 schedule과 serializable에 대해서 알아보았습니다. 지난 포스팅에 대해서 요약해봅시다. schedule은 여러 트랜잭션이 실행될 때 각 트랜잭션에 속한 operation들의 실행 순서이며, 여러 케이스의 schedule이 존재한다고 했습니다. 그리고 schedule에는 nonserial schedule과 serial schedule이 존재하며, nonserial schedule은 비정상적인 결과를 도출할 수 있습니다. 하지만 nonserial schedule이 동시에 여러 트랜잭션을 처리할 수 있어 같은 시간동안 serial schedule에 비해 더 많은 트랜잭션을 처리할 수 있습니다. 그래서 nonserial schedule이 serial schedule과 equivalent(동등한)하다면 실행시키자고 결정했습니다. nonserial schedule과 serial schedule이 equival

rolroralra

Propagation > 트랜잭션의 영역, 바운더리를 지정하기 위한 설정이다. | 종류 | 트랜잭션존재 | 트랜잭션미존재 | 비고 | | :------------ | :---------- | :------------ | :--- | | REQUIRED | 기존 트랜잭션 이용 | 신규 트랜잭션 생성 | 기본설정이다 | | SUPPORTS | 기존 트랜잭션 이용 | 트랜잭션 없이 수행 | | | MANDATORY | 기존 트랜잭션 이용 | Exception 발생 | 꼭 이전트랜잭션이 있어야 하는경우 | | NEVER | exception이 발생한다 | 정상적으로 트랜잭션 없이 수행 | 트랜잭션 없을때만 작업이 진행되어야할때 | | NOT_SUPPORTED | 트랜잭션이 종료될 때 까지 대기한 후 트랜잭션이 종료되고 나면 실행 | 트랜잭션 없이 로직이 수행 | 기존 트랜잭션에 영향을 주지 않아야할때 사용된다. | | REQUIRES_NEW | 현재 트랜잭션이 종료될 때 까지 대기

kimmin1kk

Transaction DB의 상태를 변화시키기 위해 수행하는 가장 작은 작업의 단위. 특징 (A.C.I.D) > 원자성 (Atomicity) >> Transaction은 DB에 모두 반영되거나 모두 반영되지 않아야 함 쪼갤수 없는 가장 작은 단위 = 원자 > 일관성 (Consistency) >> Transaction의 작업 처리 결과가 항상 일관성이 있어야 함 > 독립성 (Isolation) >> 어떤 하나의 Transaction이라도, 다른 Transaction의 연산에 끼어들 수 없음 > 지속성 (Durability) >> Transaction이 성공적으로 완료됐을 경우, 결과는 영구적으로 반영되어야 함 > 예시 (계좌이체) > 과정 > 구매자의 계좌에서 돈이 출금됨 판매자의 계좌에 돈이 입금됨 > Query문 예상 오류 구매자의 돈이 출금됐는데 DB가 다운된

code-10

개요 트랜잭션의 격리 수준(Isolation Level)이란 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것이다. 격리 수준은 크게 READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE 의 4가지로 나뉜다. 1. READ UNCOMMITTED READ UNCOMMITTED 격리에서는 각각 트랜잭션에서 변경 내용이 COMMIT 이나 ROLLBACK 여부에 상관없이 다른 트랜잭션에서 조회할수 있다. 예시는 아래와 같다. 사용자 A는 users id 가 1 이고 first_name 이 "Hong" 인 사원을 INSERT 사용자 B는 사용자 A가 COMMIT 하기도전에 id 가 1이고 first_name 이 "Hong" 인 사원을 검색할 수 있다. 사용자 A는 작업을 COMMIT 한다.

keikang

1. 목표 @Transactional 어노테이션의 isolation과 propagation 세팅을 알아보는게 목적 2. What Is @Transactional? (1) @Transactional Implementation Details Spring은 생성, 커밋, 롤백을 관리하기 위해 proxy를 생성하거나 byte-code클래스를 조작한다. proxy의 경우에는 내부 메소드에서의 호출을 무시한다. >Simply put, if we have a method like callMethod and we mark it as @Transactional, Spring will wrap some transaction management code around the invocation@Transactional method called 위와 같이 callMethod를 @Transactional로 설정했을 경우 callMethod가 위의 코드

duckbill

트랜잭션 (transaction) 트랜잭션 특징 원자성(Atomicity) 트랜잭션이 DB에 모두 반영되거나, 혹은 전혀 반영되지 않아야 한다.(All or nothing) 일관성(Consistency) 트랜잭션의 작업 처리 결과는 항상 일관성이 있어야 한다. 독립성(Isolation) 하나의 트랜잭션이 실행되고 있을 때 다른 트랜잭션이 중간에 끼어들수 없도록 격리성을 가져야 한다. 지속성(Durability) 트랜잭션이 성공적으로 수행되면 결과는 영구적으로 반영되어야 한다. Commit 하나의 트랜잭션이 성공적으로 끝났고, DB가 일관성 있는 상태일 때 이를 알려주기 위해 사용되는 연산 Rollback 하나의 트랜잭션 처리가 비정상적으로 종료되어 트랜잭션의 원자성이 깨진 경우 rollback을 통해 처음 상태로 되돌아가는 것 S

cyei0824

Algorithm study Backend Class Transaction Transaction은 처리되는 작업의 단위로, 데이터베이스에서의 Transaction 처리는 Business Logic 상 굉장히 중요한 기능 => 서로 다른 트랜잭션들을 처리하는 도중 하나의 단위 트랜잭션에서 에러가 발생한다면 이전에 성공했던 트랜잭션들을 다시 rollback 시켜 데이터의 Consistency가 깨지지 않도록 해줘야 함 => 성공했을 경우에는 commit ⭕️ 데이터 오염을 해결하기 위해 ACID 트랜잭션 사용 >DB의 Transaction Flow 1. 서로 다른 Transaction을 부분적으로 처리 2. 모든 Transaction이 정상적으로 완료되면 Commit 3. 만약 Transaction중 하나라도 비정상적으로 처리되면 rollback을 수행 >createQueryRunner() quer

y005

Transaction란? 데이터베이스에서의 병행제어 및 회복작업의 논리적인 단위로 하나의 트랜잭션은 하나 이상의 DML들로 구성되어 있다. 애플리케이션이 작업하는 논리적인 하나의 작업은 여러 DML로 이뤄져 있는 경우가 많고 이 작업 단위를 기준으로 회복작업과 병행제어를 해야 되기 때문에 이를 관리하기 위한 작업의 단위를 트랜잭션으로 정의하고 아래 나열된 4가지 원칙을 기준으로 트랜잭션을 관리한다. Atomicity (원자성) 하나의 트랜잭션을 이루는 DML은 트랜잭션이 성공한 경우에는 전부 반영되어야 하고 실패한 경우에는 모두 반영되지 않아야 한다. Consistent (일관성) 트랜잭션이 성공한 경우 데이터베이스 상태는 일관된 상태를 유지해야 된다. Durability (영속성) 성공한 트랜잭션의 결과는 영구적으로 반영되어야 한다. Isolation (독립성) 둘 이상의 트랜잭션이 동시에 실행되는 경우 각 트랜잭션이 다른

ej_shin

시작 전에 읽어두기 트랜잭션 DB 상태를 변화시키기 위해 수행하는 작업 단위 즉, 유저(서비스)가 정의한 쿼리 묶음 Ex. 로그인 : 중복 ID 확인 (select)와 신규 계정 생성 (insert) 트랜잭션의 ACID 원자성 (Atomicity) : 트랜잭션은 완전히 성공하거나 완전히 실패하거나 둘 중 하나의 상태를 가져야 한다. 일관성 (Consistency) : 트랜잭션의 작업 처리 결과는 항상 일관적이어야 한다. Ex. 트랜잭션 진행 중 DB가 변경되어도, 처음 참조한 DB로 트랜잭션을 진행해야 한다. 격리성 (Isolation) : 둘 이상의 트랜잭션이 실행될 때, 그 어떤 트랜잭션도 다른 트랜잭션의 연산을 침범할 수 없다. 지속성 (Durability) : 트랜잭션이 성공적으로 완료되었을 때, 해당 트랜잭션의 결과는 DB에 영구적으로 반영되어야 한다. 전파 속성 (P

xlwdn98767

낮은 단계의 트랜잭션 고립화 수준 사용 시 발생하는 현상 Dirty Read 트랜잭션이 rollback하였음에도 다른 트랜잭션이 rollback되기 이전의 데이터를 갖고 있는 경우 → 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽을 수 있도록 허용할 때 발생(오라클에선 해당 문제 발생 x) Non-Repeatable Read 트랜잭션이 수행되는 동안 다른 트랜잭션에 의해 값이 변경, 또는 삭제되어(update/delete) 데이터의 일관성이 보장되지 않는 현상 → 트랜잭션을 수행하는 동안 두 쿼리의 결과가 상이하게 나타나 비일관성이 발생하는 것. Phantom Read 트랜잭션 수행 중, 다른 트랜잭션에 의해 데이터가 추가되고 다시 읽었을 때 유령 레코드가 발생하는 현상 트랜잭션 수준 읽기 일관성 문장 수준 읽기 일관성 쿼리가 시작된 시점 기준으로 일관성 있게 데이터를 읽

abcdeeefg

Transaction Isolation Level 문제점 Dirty Read Dirty Read는 다른 트랜잭션에 의해 수정됐지만 아직 커밋되지 않은 데이터를 읽는 것을 말한다. 예시 A트랜잭션에서 10번 사원의 나이를 27살에서 28살로 바꾼다. 아직 커밋하지 않는다. B 트랜잭션에서 10번 사원의 나이를 조회한다. 그러면 아직 커밋하지 않은 28살이 조회된다. -> Dirty Read 발생 A 트랜잭션에서 문제가 발생한 ROLLBACK한다. B 트랜잭션은 10번 사원이 여전히 28살이라고 생각하고 로직을 수행한다. 이런식으로 데이터 정합성에 문제가 많으므로, RDBMS 표준에서는 격리수준으로 인정하지도 않는다. (정합성 : 데이터의 값이 서로 일치하는 상태) , (무결성 : 데이터의 값이 정확한 상태) 즉 Dirty Read는 모든 DB에서 허용하면 안된다. 롤백 문제가 있기 때문이다. Non-R

denhur62

오늘은 트랜잭션의 전파 수준과 격리 수준에 대해서 이야기해보고자 한다. 트랜잭션에서의 격리는 한 트랜잭션에서 데이터가 수정되는 과정이 다른 트랜잭션과는 독립적으로 진행되어야 한다는 특성이다. 이 때 독립되는 수준을 4가지로 나눌수 있으며 각각에 대해 알아보자 트랜잭션 격리 수준 혹은 트랜잭션 읽기 일관성은 아래의 4가지와 같다. READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE 우선적으로 트랜잭션 격리 수준을 정할 때에는 동시성 과 정합성이 반비례 한다는 것이다. 트랜잭션의 성능이 좋으면 특정 데이터에 대해서 일관성, 정합성 이 좋지 않지만 동시성이 좋지 않으면 그만큼 일관성 있는 데이터를 제공한다. ![](https://velog.velcdn.com/images/denhur62/post/d9f804a8-a266-4edd-b5

hyunjong96

트랜잭션 격리 수준 트랜잭션 격리 수준이란, 동시에 여러개의 트랜잭션이 수행될 때 각 트랜잭션이 얼만큼의 고립성을 가지는지 나타내는 것. 즉, 특정 트랜잭션이 다른 트랜잭션에 변경된 데이터를 보여줄것인지에 대한 여부를 나타내는 것. 격리 수준은 4가지로 나뉜다. Read UnCommited Read Commited Repetable Read Serializable Read UnCommited 특정 트랜잭션에서 변경된 데이터를 트랜잭션이 commit(), Rollback 여부와 상관없이 다른 트랜잭션에게 보여지는 격리 수준. 참조 : https://nesoy.github.io/articles/2019-05/Database-Transa

kdh10806

1. Isolation Level >트랜잭션 격리수준(Isolation Level)이란 동시에 여러 트랜잭션이 처리될 때, 트랜잭션끼리 얼마나 서로 고립되어 있는지를 나타내는 것이다. 즉, 특정 트랜잭션이 다른 트랜잭션에 변경한 데이터를 볼 수 있도록 허용할지 말지를 결정한다. 데이터베이스는 ACID 특징과 같이 트랜잭션이 독립적인 수행을 하도록 Locking을 통해, 트랜잭션이 DB를 다루는 동안 다른 트랜잭션이 관여하지 못하도록 막는 것이 필요하다. 하지만 무조건 Locking을 사용하여 동시에 수행되는 수많은 트랜잭션들을 순서대로 처리하는 방식으로 구현하게 되면 데이터베이스의 성능은 떨어지게 된다. 하지만, 성능을 높이기 위해 Locking의 범위를 줄인다면 잘못된 값이 처리될 문제가 발생할 수 있다. ✅ 잠금(Lock) - 동시성 제어 > DB관리에서 하나의 트랜잭션에 사용되는 데이터를 다른 트랜잭션이 접근하지 못하게 하는 것 ⓵ 잠금

ko1586

1. Transaction >* Transaction이란, 단어 그대로 보면 거래라는 뜻이다. 하지만, 개발에서도 비슷한 부분에서 쓰이긴 한다. 이것은 데이터베이스의 상태를 변화시키기 위해 수행하는 작업의 단위를 뜻한다. 간단히 말해, 질의어(SQL)를 이용하여 데이터베이스를 접근 하는 것을 의미한다. (SELECT, INSERT, DELETE, UPDATE) 개발자가 하나의 트랜잭션 설계를 잘하는 것이 데이터를 다루는 것에 많은 이점이 있다. >* 서비스에서 가장 큰 문제는 데이터의 오염이라고 하는데, 에러가 나오는데 데이터가 계속 저장되면, 데이터베이스 안은 오염이 되어 어지럽기 일쑤다. 그래서 차라리 실패할거면 전체 다 실패하고, **다시 시도하는게 안전하다는게 트랜잭션의