# transaction
Transaction VS UserOperation
Legacy Transaction EIP-1559 즉, 새로운 트랜잭션 타입이 추가되기 전에 사용되었던 트랜잭션 구조이며, Legacy 트랜잭션이라고 부르고 트랜잭션 타입은 0x0이다. EIP-1559와 가장 큰 차이점은 수수료 정책인데, 레거시 트랜잭션은 블록 채굴자들이 블록 채굴 보상으로 블록에 포함되는 모든 거래들의 수수료를 가져가는 구조였기 때문에, 가스비 경쟁이 심화되는 구조였다. 채굴자들은 가스비를 더 많이 가져가기 위해서 가스비가 높은 트랜잭션 위주로 블록에 담게되고, 사용자들은 자신의 거래가 빨리 수행되도록 하기 위해서 점점 더 높은 수수료를 내게 되고 블록에 채택되길 기다려야 했다. 또한 기술적인 차이는 블록의 크기이다. EIP-1559로 업그레이드 하기 전, 모든 블록은 동일한 크기를 가졌다고, 그에 따라 처리할 수 있는 트랜잭션의 수량 또한 일정했다. 따라서 거래가 몰리는 시간이면 블록을 생성하는 시간보다 처리해야할 트랜잭션의 수가
트랜잭션이란?
트랜잭션은 무엇인가? 데이터베이스는 초당 수백만개의 동시 요청을 수행할 수 있는 걸로 알려져 있습니다. 일반적으로, 이러한 요청들은 데이터 베이스에 있는 동일한 데이터를 조작할 수 있습니다. 예를들어 온라인 쇼핑 사이트에서 한정판 게임을 살려고 할 때, 여러 사용자들이 동시에 장바구니에 해당 게임을 담았고 그와 동시에 구매하기를 눌렀다고 가정해보겠습니다. 이 경우에 남아있는 수량은 초과도 과소도 아닌 정확하게 계산되어야합니다. 일반적으로 데이터베이스의 트랜잭션은 이런 상황에서 사용됩니다. 그래서 트랜젝션이 뭐지? 간단히 말하면, 데이터베이스 트랜잭션은 데이터베이스에서 수행되는 여러 작업의 연속이며(SQL문의 집합), 이러한 작업들은 모두 하나의 논리적인 작업 단위로 취급되어 전체가 완전히 수행되거나 전혀 수행되지 않습니다. 다시 말하면, 작업 중 일부만 수행되고 결과가 저장되는 경우는 절대 없습니다. 데이터베이스 트랜잭션이 진행 중일 때 데이터베이스
트랜잭션 이슈 회고
이슈 발생 어느 날 팀원분이 외부 서비스를 사내 서비스와 연동하는 도중에 도움을 요청하셨다. api호출로 DB에 값을 넣고 외부 서비스에서 사내 서비스 api 호출로 데이터를 조회해보면 불규칙적으로 데이터 조회가 안되는 이슈가 발생했기 때문이었다. 해당 상황을 간략히 정리하면 아래와 같다. A로직을 호출하면 a데이터를 저장한다. 데이터 저장 후 외부 서비스를 HTTP 호출한다. 외부 서버에서는 우리 서버의 B로직을 api 호출해서 a데이터를 조회한다. 불규칙적으로 a데이터가 없다고 조회된다. 문제 상황 유추 나는 원인을 파악하기 위해 우리 서버의 코드부터 확인해보았다. 문제가 된 자바 Spring 의사코드는 아래와 같다 코드를 검토한 결과, Spring의 트랜잭션 관련 어노테이션(@Transactional)이 원인일 것으로 추정되었다. 외부 서버는 호출 받은 즉시 데이터를 조회한다고 가정했을 때 코드의 흐름을 정리해보면
Spring - Transaction [IT 국비지원/구디 아카데미/김지훈 강사님]
Transaction Transaction은 Data Base에서 사용되는 쪼갤 수 없는 업무처리의 단위이다. 실생활에서 하나 이상의 동작이지만 분리해서 실행 할 수 없는 상황에는 무엇이 있을까
2023.09.07.THU
mac 원격 접속 : vpn 설정 후, 파인더 들어가서 command+k 눌러서 연결하면 됨. microsoft remote desktop 앱 깔아서 하려다가 계속 연결 안 돼서 고생하다가 결국 내장 프로그램으로 연결함. https://picory.com/entry/MAC-%EC%9B%90%EA%B2%A9-%EC%A0%91%EC%86%8D-VNC-%ED%8F%AC%ED%8A%B8-%EB%B3%80%EA%B2%BD Could not instantiate bean class [java.util.List]: Specified class is an interface 에러 https://mchch.tistory.com/78 서비스에서 트랜잭션 안 붙여서 난 에러 No transaction aspect-managed TransactionStatus in scope
[Redis] Transactions, 트랜잭션
Redis Transactions(이하 Transactions)는 명령어 그룹을 한 번에 처리할 수 있도록 해준다. 관련 명령어 목록: MULTI EXEC DISCARD WATCH Transactions는 중요한 두 가지를 보장해준다. 트랜잭션의 모든 명령은 순차적으로 직렬화되고 실행된다. 다른 클라이언트의 요청이 오면 절대 실행 중간에 그 요청이 실행되지 않는다. 이것은 명령어가 단일 분리된 작업으로 실행되는 것을 보장한다. EXEC 명령어는 트랜잭션의 모든 명령을 실행시킨다. 클라이언트가 EXEC 명령을 호출하기 전에 트랜잭션의 컨텍스트에서 서버와의 연결이 끊긴 다면 모든 작업은 실행되지 않는다. 사용 방법 MULTI라는 명령어를 치면 OK라는 싸인과 함께 여러 명령어를 받을 준비가 된다. 바로바로 실행되던 것과 달리 Redis는 명령어를 큐(Queue)에 넣는다. EXEC 명령어가 들어올 때 실행된다. `
트랜잭션 이해하기
트랜잭션(Transaction)이란? 트랜잭션을 해석하면 거래라는 뜻인데, 트랜잭션은 데이터베이스에 실행한 로직을 안전하게 처리하도록 보장해준다. 예를 들어보자, 만약 A라는 사람이 B라는 사람에게 10000원을 이체해준다고 가정해보자. 이체가 성공적으로 마무리 되었다면 문제가 없겠지만 만약 A라는 사람이 송금은 완료되었는데 B라는 사람이 전달받을 때 문제가 생기게 된다면 A라는 사람의 돈만 10000원이 사라지게 된다. 이러한 문제를 방지하기 위해 사용하는 것이 트랜잭션이라는 기술이다. 트랜잭션을 사용해 계좌이체를 성공했다면 모든 작업을 정상 반영하도록 commit을 해주고, 작업 중간에 실패했다면 rollback하여 사용자들에게 문제가 없도록 해준다. 그래서 트랜잭션은 ACID라고 하는 것을 보장해야 한다. 원자성(Atomicity) 일관성(Consistency) 격리성(Isolation) **지속성
[IT국비지원] 개발자 교육 26일 차 : DB(2023.08.31)fit.구디아카데미,김지훈 강사님
이하 구디아카데미 김지훈 강사님의 수업자료와 강의 내용 정리, 실습한 내용을 정리함 > 벌써 목요일이라니 시간 참 빠르다（⊙ｏ⊙）(⊙ˍ⊙)（⊙ｏ⊙）（⊙ｏ⊙） SELETE 특정 조건의 데이터 조회 select [컬럼 이름] from [테이블명] where [조건] AND 조건 : select [컬럼 이름] from [테이블명] where [조건] and [조건] OR 조건 : select [컬럼 이름] from [테이블명] where [조건] or [조건] BETWEEN AND : select [컬럼 이름] from [테이블명] where [조건 대상] between [조건] and [조건] 중복 제거 SELECT DISTINCT [컬럼] FROM [
[DB] MVCC(다중 버전 동시성 제어)란?
들어가며 해당 강의를 보고 공부한 내용을 정리하였습니다. 이전 글에서는 Lock과 함께 2PL protocol을 살펴보았습니다. 해당 개념을 살펴보면서 데이터 전체 처리량에 대한 문제가 발생하였고 이를 해결하기 위해 MVCC를 사용하였다고 정리하였습니다. 이번 글에서는 MVCC에 대해 자세히 살펴보겠습니다. MVCC 등장배경
LOCK을 활용한 concurrency control 기법
들어가며 해당 강의를 보면서 공부한 내용을 정리하였습니다. Lock 개념 Lock은 데이터베이스에서 동시성 제어를 위해 사용되는 메커니즘으로, 동일한 데이터에 여러 트랜잭션이 동시에 접근하는 것을 제어하는 데 활용됩니다. write_lock (exclusive lock) read / write(insert, update, d
transaction isolation level 개념 정리 #2
들어가며 이전 글에서 이어집니다. 이전 글에서는 이상현상에 대해 주로 살펴보았습니다. 이번 글에서는 Snpashot Isolation과 Isolation level에 대해 살펴보겠습니다. Isolation level 배경 앞서 살펴본 이상한 현상들이 모두 발생하지 않게 만들 수 있지만 그러면 제약사항이 많아져서 동시 처리 가능한 트랜잭션 수가 줄어들어 결국 DB의 전체 처리량이 하락하게 됩니다. 그러던 중, 일부 이상한 현상을 허락하는 몇 가지 level을 만들어서 사용자가 필요에 따라 적절하게 선택할 수
transaction isolation level 개념 정리 #1
들어가며 해당 강의를 보면서 공부한 내용을 정리하였습니다. dirty read 개념 Dirty Read는 데이터베이스 트랜잭션의 일관성과 격리 수준을 위반하는 현상입니다. 여기서 "Dirty"란 아직 커밋되지 않은 데이터 변경을 의미합니다. 특정 트랜잭션이 데이터를 수정한 후 커밋하지 않은 상태에서 다른 트랜잭션이 해당 변경사항을 읽는 경우를 가리킵니다. 예시 트랜잭션 A가 데이터 X의 값을 읽습니다. 트랜잭션 B가 Y값을 70으로 수정합니다. 트랜잭션 A가 아직 커밋되지 않은 변경
[Spring] Spring AOP 사용 시 주의점 (With @Transactional)
문제 상황 실무에서 @Transactional 어노테이션을 사용하면서 겪은 문제이다. 다음과 같은 코드에서 문제가 발생했다. IntelliJ의 플러그인으로 사용하고 있는 SonarLint에서 버그를 감지했는데, 메세지를 확인해 보면 다음과 같다. 확인해보면 실제 트랜잭션이 동작되지 않는다고 써있는데, 그 이유는 뭘까? @Transactional의 동작 원리 먼저 @Transactional은 스프링AOP 기반(프록시)으로 동작된다. 스프링 AOP는 부가기능(Advice)을 적용할 대상(Pointcut)에 대해 런타임에 프록시를 생성하고, 생성한 프록시를 빈으로 등록해서 사용하게 된다. 
Transaction
출처 김영한 강사님의 Spring DB 1편 📗 Transaction이란? 트랜잭션은 데이터베이스에서 하나의 거래를 안전하게 처리하도록 보장해주는 것을 뜻한다. 모든 작업이 성공해서 DB에 정상 반영하는 것을 Commit이라 하고 작업 중 하나라도 실패해서 거래 이전으로 되돌리는 것을 Rollback이라 한다. 📄 ACID 트랜잭션의 ACID는 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)을 보장해야 한다. 원자성(Atomicity) 트랜잭션 내에서 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공하거나 모두 실패해야 한다. 일관성(Consistency) 모든 트랜잭션은 일관성 있는 DB 상태를
스프링 DB 1편 데이터 접근 핵심 원리 - 예외의 이해와 사용
자바 예외 이해 예외에 대해서는 2가지 기본 규칙이 있다. 예외는 잡아서 처리하거나 던져야 한다. 예외를 잡거나 던질 때 지정한 예외뿐만 아니라 그 예외의 자식들도 함께 처리된다. 예를 들어서 Exception 을 catch 로 잡으면 그 하위 예외들도 모두 잡는다. 예를 들어서 Exception 을 catch 로 던지면 그 하위 예외들도 모두 던는다. 참고: 예외를 처리하지 못하고 계속 던지면 어떻게 될까? 자바 main() 쓰레드의 경우 예외 로그를 출력하면서 시스템이 종료된다. 웹 애플리케이션의 경우 여러 사용자의 요청을 처리하기 때문에 하나의 예외 로 시스템이 종료되면 안 된다. WAS가 처리하며 보통 오류 페이지를 보여준다. 다음으로 체크 예외와 언체크 예외의 차이에 대해서 코드로 학습하자. 체크 예외 기본 이해 Exception 및 하위 예외는 모두 컴파일러 체크 단 `RuntimeExcept
스프링 DB 1편 데이터 접근 핵심 원리 - DataSource의 이해
커넥션을 얻는 방법은 DriverManager를 사용하거나 커넥션 풀을 사용한다. 드라이버 매니저를 통해 획득. DriverManager -> 커넥션 풀로 변경하려면 ? 애플리케이션 로직에서 DriverManager 를 사용해서 커넥션 획득 → 커넥션 풀을 사용하게 변경 즉, 커넥션 획득에 필요한 애플리케이션 코드도 변경해야 한다. 즉, 의존관계 변경되어 사용법도 상이 
스프링 DB 1편 데이터 접근 핵심 원리 - 커넥션 풀의 이해
커넥션 풀 이해 
스프링 DB 1편 데이터 접근 핵심 원리 - 트랜잭션의 문제 해결과 AOP의 이해
트랜잭션 문제 해결 - 트랜잭션 AOP 이해 지금까지 트랜잭션을 편리하게 처리하기 위해서 추상화도 도입하고 , 템플릿도 도입했다. 템플릿 덕분에 트랜잭션을 처리하는 반복코드를 해결했다. 하지만 서비스 계층에 순수 비즈니스 로직만을 남기는 것은 아직 성공하지 못했다. 이럴때 스프링 AOP를 통해 프록시를 도입하여 문제를 해결해보겠다. 프록시를 사용하면 트랜잭션을 처리하는 객체와 비즈니스 로직을 처리하는 서비스 객체를 분리할 수 있다. 트랜잭션 프록시 코드 예시 트랜잭션 프록시 적용 후 서비스 코드 예시 프록시 도입 전 : 서비스에 비즈니스 로직과 트랜잭션 처리 로직이 함께 섞여있다. 프록시 도입 후: 트랜잭션 프록시가 처리 로직을 모두 가져가고 트랜잭션 시작→ 실제서비스 호출 트랜잭션 프록시 덕분에 서비스 계층에는 순수한 비즈니스 로직만 남길 수 있다. 아래의 사진은 트랜잭션 AOP의 전체 흐름이다. [제공, 김영한 강사]
스프링 DB 1편 데이터 접근 핵심 원리 - 트랜잭션 추상화
트랜잭션 추상화 현재 서비스 계층은 트랜잭션으르 사용하기 위해 JDBC에 의존하고 있다. 향후 다른 데이터 접근 기술로 변경하면, 서비스 계층의 트랜잭션 코드 모두 함께 수정해야 한다. 구현 기술에 따른 트랜잭션 사용법 트랜잭션은 원자적 단위의 비즈니스 로직을 처리하기 위해 사용한다. 구현 기술마다 트랜잭션을 사용하는 방법이 다르다. JDBC : con.setAutoCommit(false) JPA : transaction.begin() JDBC 트랜잭션 코드 예시 JPA 트랜잭션 코드 예시 java pulic static void main(String[] args) { //엔티티 매니저 팩토리 생성 EntityManagerFactory emf = Persistence.createEntityManager
스프링 DB 1편 데이터 접근 핵심 원리 - 트랜잭션 적용 중 문제점들
문제점들 애플리케이션 구조 프래젠테이션 계층 UI와 관련된 처리 담당 웹 요청과 응답 사용자 요청을 검증 주 사용 기술: 서블릿과 HTTP 같은 웹 기술, 스프링MVC 서비스 계층 비즈니스 로직을 담당 주 사용 기술: 가급적 특정 기술에 의존하지 않고, 순수 자바 코드 작성 데이터 접근 계층 실제 데이터베이스에 접근하는 코드 주 사용 기술:JDBC, JPA,File,Redis,Mongo … 순수한 서비스 계층 여기서 가장 중요한 곳은 핵심 비즈니스 로직이 들은 서비스 계층이다. 데이터 저장 기술을 변경해도 비즈니스 로직은 최대한 변경없이 유지되어야 한다. 이럴려면 ? 서비스 계층을 특정 기술에 종속적이지 않게 개발. 종속적인 부분