일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 그리디
- kotlin
- 인프런
- db
- java
- transaction
- pointcut
- Thymeleaf
- 스프링
- http
- jpa
- QueryDSL
- 알고리즘
- 스프링 핵심 기능
- AOP
- 자바
- Greedy
- 스프링 핵심 원리
- Servlet
- Android
- SpringBoot
- Exception
- spring
- JPQL
- Spring Boot
- springdatajpa
- Proxy
- 김영한
- JDBC
- 백준
- Today
- Total
목록전체 글 (893)
개발자되기 프로젝트
애플리케이션에서 트랜잭션을 어떤 계층에 걸어야 할까? 쉽게 이야기해서 트랜잭션을 어디에서 시작하고, 어디에서 커밋해야할까? 비즈니스 로직과 transaction 트랜잭션은 비즈니스 로직이 있는 서비스 계층에서 시작해야 한다. 비즈니스 로직이 잘못되면 해당 비즈니스 로직으로 인해 문제가 되는 부분을 함께 롤백해야 하기 때문이다. 그런데 트랜잭션을 시작하려면 커넥션이 필요하다. 결국 서비스 계층에서 커넥션을 만들고, 트랜잭션 커밋 이후에 커넥션을 종료해야 한다. 애플리케이션에서 DB 트랜잭션을 사용하려면 트랜잭션을 사용하는 동안 같은 커넥션을 유지해야한다. 그래야 같은 세션을 사용할 수 있다. 커넥션과 세션 애플리케이션에서 같은 커넥션을 유지하려면 어떻게 해야할까? 가장 단순한 방법은 커넥션을 파라미터로 전..
MemberServiceV1 package hello.jdbc.service; import hello.jdbc.domain.Member; import hello.jdbc.repository.MemberRepositoryV1; import lombok.RequiredArgsConstructor; import java.sql.SQLException; @RequiredArgsConstructor public class MemberServiceV1 { private final MemberRepositoryV1 memberRepository; private void accountTransfer(String fromId, String toId, int money) throws SQLException { Member..
일반적인 조회는 락을 사용하지 않는다 데이터베이스마다 다르지만, 보통 데이터를 조회할 때는 락을 획득하지 않고 바로 데이터를 조회할 수 있다. 예를 들어서 세션1이 락을 획득하고 데이터를 변경하고 있어도, 세션2에서 데이터를 조회는 할 수 있다. 물론 세션2에서 조회가 아니라 데이터를 변경하려면 락이 필요하기 때문에 락이 돌아올 때 까지 대기해야 한다. 조회와 락 데이터를 조회할 때도 락을 획득하고 싶을 때가 있다. 이럴 때는 select for update 구문을 사용하면 된다. 이렇게 하면 세션1이 조회 시점에 락을 가져가버리기 때문에 다른 세션에서 해당 데이터를 변경할 수 없다. 물론 이 경우도 트랜잭션을 커밋하면 락을 반납한다. 조회 시점에 락이 필요한 경우는 언제일까? 트랜잭션 종료 시점까지 해..
문제 항승이는 품질이 심각하게 나쁜 수도 파이프 회사의 수리공이다. 항승이는 세준 지하철 공사에서 물이 샌다는 소식을 듣고 수리를 하러 갔다. 파이프에서 물이 새는 곳은 신기하게도 가장 왼쪽에서 정수만큼 떨어진 거리만 물이 샌다. 항승이는 길이가 L인 테이프를 무한개 가지고 있다. 항승이는 테이프를 이용해서 물을 막으려고 한다. 항승이는 항상 물을 막을 때, 적어도 그 위치의 좌우 0.5만큼 간격을 줘야 물이 다시는 안 샌다고 생각한다. 물이 새는 곳의 위치와, 항승이가 가지고 있는 테이프의 길이 L이 주어졌을 때, 항승이가 필요한 테이프의 최소 개수를 구하는 프로그램을 작성하시오. 테이프를 자를 수 없고, 테이프를 겹쳐서 붙이는 것도 가능하다. 입력 첫째 줄에 물이 새는 곳의 개수 N과 테이프의 길이 ..
기본 데이터 입력 set autocommit true; delete from member; insert into member(member_id, money) values ('memberA',10000); lock 0 lock 1 - 세션1 set autocommit false; update member set money=500 where member_id = 'memberA'; 세션1이 트랜잭션을 시작하고, memberA 의 데이터를 500원으로 업데이트 했다. 아직 커밋은 하지 않았다. memberA 로우의 락은 세션1이 가지게 된다. lock 2 - 세션 2 SET LOCK_TIMEOUT 60000; set autocommit false; update member set money=1000 where..
세션1이 트랜잭션을 시작하고 데이터를 수정하는 동안 아직 커밋을 수행하지 않았는데, 세션2에서 동시에 같은 데이터를 수정하게 되면 여러가지 문제가 발생한다. 바로 트랜잭션의 원자성이 깨지는 것이다. 여기에 더해서 세션1이 중간에 롤백을 하게 되면 세션2는 잘못된 데이터를 수정하는 문제가 발생한다. 이런 문제를 방지하려면, 세션이 트랜잭션을 시작하고 데이터를 수정하는 동안에는 커밋이나 롤백 전까지 다른 세션에서 해당 데이터를 수정할 수 없게 막아야 한다. lock 0 세션1은 memberA 의 금액을 500원으로 변경하고 싶고, 세션2는 같은 memberA 의 금액을 1000원으로 변경하고 싶다. 데이터베이스는 이런 문제를 해결하기 위해 락(Lock)이라는 개념을 제공한다. lock 1 세션1은 트랜잭션을..
세 가지 상황을 가정해보자. 계좌이체 정상 계좌이체 문제 상황 - 커밋 계좌이체 문제 상황 - 롤백 1. 계좌이체 정상 기본 데이터 입력 - SQL set autocommit true; delete from member; insert into member(member_id, money) values ('memberA',10000); insert into member(member_id, money) values ('memberB',10000); memberA 10000원 memberB 10000원 계좌이체 실행 memberA 의 돈을 memberB 에게 2000원 계좌이체하는 트랜잭션을 실행해보자. 다음과 같은 2번의 update 쿼리가 수행되어야 한다. set autocommit false 로 설정한다...
1. 기본 데이터 입력 먼저 H2 데이터베이스 웹 콘솔 창을 2개 열어두자. 주의! H2 데이터베이스 웹 콘솔 창을 2개 열때 기존 URL을 복사하면 안된다. 꼭 http://localhost:8082 를 직접 입력해서 완전히 새로운 세션에서 연결하도록 하자. URL을 복사하면 같은 세션( jsessionId )에서 실행되어서 원하는 결과가 나오지 않을 수 있다 기본 데이터 데이터 초기화 SQL //데이터 초기화 set autocommit true; delete from member; insert into member(member_id, money) values ('oldId',10000); 2. 신규 데이터 추가 - commit 전 세션1에서 신규 데이터를 추가해보자. 아직 커밋은 하지 않을 것이다. ..