# transaction isolation
Transaction Isolation Level
https://velog.io/@guswlsapdlf/Transaction-Model 이전에도 transaction isolation level에 관한 글을 쓴 적이 있지만, 내용을 더 추가하고자 글을 작성하게 되었다. Transaction Isolation Level 여러 트랜잭션이 발생했을 때, 각 트랜잭션이 다른 트랜잭션에 어느 정도까지 영향을 받게 설정할지 그 수준을 정의한 것이 바로 transaction isolation level이다. REPEATABLE READ Inno DB의 기본 값으로 트랜잭션이 시작할 때 snapshot을 뜨고 해당 snapshot에서 계속 데이터를 읽는다. 이를 통해 동일 트랜잭션 내에서 동일한 값을 읽기가 가능하다. 하지만 다른 트랜잭션에서 snapshot에 포함된 데이터를 수정했을 때 그 데이터를 다시 읽으면 이전과는 전혀 다른 값을 읽게 되는데 이와 같은 현상을 PHANTOM READ라고 한다. MySQL DB의 경우
Transaction isolation level
트랜잭션의 격리 수준(isonation)이란? > 동시에 트랜잭션이 처리될 때 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있도록 허용할지 말지를 결정하는것 트랜잭션 격리 수준(Isolation Level)의 종료 READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE 1. READ UNCOMMITTED 아직 Commit되지 않은 데이터를 다른 트랜잭션이 읽는것을 허용한다. 정합성에 문제가 많은 격리 수준이기 때문에 사용하지 않는 것을 권장한다. DIRTY READ현상 발생, 트랜잭션이 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있게 되는 현상을 말한다. 2. READ COMMITTED RDB에서 대부분 기본적으로 사용되고 있는 격리 수준이다. DIRTY READ와 같은 현상은 발생하지 않는다. 데이터를 변경할 때 이전 데이터를 Undo

@Transactional 상황별 commit, rollback 전략
Overview 스프링을 사용하여 개발을 하면서 예외를 가장 예민하게 처리하는 기능 중 하나가 @Transactional입니다. @Transactional은 우리가 아는 데이터베이스의 트랜잭션과 같이 ACID의 특징을 가지면서 더 이상 쪼갤 수 없는 최소 단위의 작업입니다. 트랜잭션 경계안에서 진행된 작업은 commit을 통해 성공하거나 rollback을 통해 모두 취소되어야 합니다. 애플리케이션 수준에서 논리적인 단위로 트랜잭션을 묶습니다. 스프링에서는 이를 메서드 단위로 묶습니다. 이를 명시적으로 선언하기 위해 우리는 인터페이스, 클래스, 메서드 등의 @Transactional을 붙여주기만 하면 됩니다. image 그런데 이놈의 @Transactional은 사용
데브코스 W5D5
AoP(Aspect Orient Programming) 관점 지향 프로그래밍이라는 뜻으로 계층 안에서가 아닌 계층마다 가지고 있는 공통 관심사의 분리를 허용함으로써 모듈성을 증가시키는 것이 목적인 프로그래밍 패러다임이다. 특히 로깅이나 트랙잭션 관리, 보안과 같이 특정 계층 내에서만 실행되지 않고 반복되어 수행되는 관심사를 추상화시켜서 분리시키면 개발자는 핵심 비즈니스 로직에 집중할 수 있게 하는 장점을 가지고 있다. + Proxy 동작 수행에 대한 지시를 대신 수행해주는 객체를 의미해서 사용자가 직접 동작에 대한 지시가 어려운 경우 주로 사용된다. 스프링의 AoP에서는 클라이언트와 타깃 사이에 투명하게 존재해서 타깃의 메소드 전후로 부가기능을 제공하기 위해 프록시 구조를 활용하고 있다. @AspectJ Spring에서 제공되는 아노테이션 기반 서비스로 횡단 관심사를 가진 모듈에 아노테이션을 붙여 사용하면 자동으로 AoP 환경을 구축해주는 것이 특징이다.