qwef

cud 뿐만 아니라 조회하는 순간에 락을 가져갈 수 있다. select 문 + for update 하면 된다. set autocommit false; select * from member where member_id='memberA' for update; 물론 이 순간에도 후에 commit이나 rollback 하면 락을 반납한다. 뭔가 내가 계산이 끝나기 전 까지 다른 세션에서 update 하지 못하도록 하고 싶을 때 쓴다고 한다. 내가 뭔가 복잡한 처리를 끝마칠 때 까지 다른 세션이 건들지 못하도록 하고 싶을 때.

세션 1이 아직 commit을 안했는데 세션 2에서 (혹은 세션 1에서도) 같은 데이터를 접근 시 수정하면 뭔가 문제가 될 수도 있다. 그래서, 세션 1이 그 데이터들을 commit 혹은 rollback 하기 전 까지 lock 해 버린다. 아마 bool isAutoCommitMode = false; static ArrayList temps; 이런 식으로 각 세션마다 되어 있고, 실제 데이터 등록하는 그런 거는 cud(Data data) foreach( Data tempData : temps){ if(tempData.equals(data)){ throw new Error("data is Locked"); } } ~~~~ temps.add(data); if(isAutoCommitMode){ data.comm..

DB에서 set autocommit true 하면 자동커밋(기본값) set autocommit false 하면 수동커밋 자동커밋은 쿼리 한 줄을 완료할 때마다 커밋 됨. 편리하지만, 우리가 원하는 commit, rollback의 트랜잭션 기능을 활용할 수는 없다. 예를 들면 5천원 계좌이체 일 때 update member set money = money + ? where member_id = ?; 첫번째 ?가 5천원, 두번째 ?가 A, update member set money = money - ? where member_id = ?; 첫번째 ?가 5천원, 두번째 ?가 B 이 두개가 완벽히 실행되어야 송금이 이루어 지는 것 이므로, 저거 두개가 완벽히 실행 된 이후에 commit을 하고 싶다는 거다. 커..

사실 내부의 트랜잭션 동작은 DB마다 다 다르긴 함. 이것도 예시의 하나 이긴 함. DB 변경 쿼리를 실행하고, 그 결과를 DB에 저장하려면 commit, 저장하고 싶지 않다면 rollback commit 호출 전 까지 데이터는 임시로 저장하는 것임. 사실 우리가 그냥 쿼리만 날려도 DB에 저장이 되었는데, 그게 오토 커밋 모드라서 그럼. 수동 커밋 모드면 우리가 직접 commit도 해 줘야 함. 이런 느낌이다. 세션 1에서 테이블 조회하면 볼 수 있지만, 다른 세션에서 조회하면 볼 수 없다. 저렇게 세션 1에서만 임시로 보이고, 커밋을 해야 비로소 DB에 제대로 저장이 되는 것이다. 만약 커밋 되지 않은 상태로 트랜잭션 레벨을 설정해서 볼 수 있다고 가정했을 때, 세션 1이 저렇게 해놓은 상태에서, 세..

이런 식. 우리가 저번에 만들었던 코드들에서 getConnection 하는 것 처럼 DB에서로부터 커넥션을 얻는거임. 그리고 커넥션이 생기면 그 커넥션은 세션을 만들고, 이 세션이 sql, 트랜잭션 등 주요 업무를 수행한다. DB의 세션은 커넥션을 닫거나, DB관리자가 강제로 세션을 종료하면 종료됨 커넥션 풀

사실 데이터를 저장하려면 파일에 그냥 저장해도 된다. 근데 DB를 굳이 쓰는 이유는? DB는 트랜잭션이라는 개념을 지원하기 때문. 트랜잭션(Transaction)을 직역하면 거래라는 뜻인데, 트랜잭션은 하나의 안전한 거래를 보장해준다는 거다. 예를 들어 A와 B가 계좌이체를 한다고 했을 때, A의 잔고에서 5천원이 감소하고, B의 잔고에서 5천원이 증가하여야 한다. 근데 만약 A의 잔고에서 5천원이 감소한 상황에서, B의 잔고에서 5천원을 증가시키려고 했을 때 오류가 발생한다면? 그냥 A의 돈만 날리는 거다. 이러 한 점을 방지하기 위해, DB가 제공하는 트랜잭션 기능이란 저 둘이 하나라도 실패하면 거래 전의 상태로 돌아가 준다. 모든 작업을 성공해 DB에 정상 반영하는 것을 커밋(commit), 작업 ..

@Slf4j public class MemberRepositoryV1 { private final DataSource dataSource; public MemberRepositoryV1(DataSource dataSource) { this.dataSource = dataSource; } private void close(Connection con, Statement stmt, ResultSet rs){ JdbcUtils.closeResultSet(rs); JdbcUtils.closeStatement(stmt); JdbcUtils.closeConnection(con); } private Connection getConnection() throws SQLException { Connection con = d..

@Slf4j public class ConnectionTest { @Test void dataSourceConnectionPool() throws SQLException, InterruptedException { HikariDataSource dataSource = new HikariDataSource(); dataSource.setJdbcUrl(URL); dataSource.setUsername(USERNAME); dataSource.setPassword(PASSWORD); dataSource.setMaximumPoolSize(10); dataSource.setPoolName("MyPool"); userDataSource(dataSource); } private void userDataSource(Da..

@Slf4j public class ConnectionTest { @Test public void dataSourceDriverManager() throws SQLException { DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD); userDataSource(dataSource); } private void userDataSource(DataSource dataSource) throws SQLException { Connection con1 = dataSource.getConnection(); Connection con2 = dataSource.getConnection(); log.info(..

커넥션을 얻는 다양한 방법. 근데 우리는 결과적으로 HikariCP 커넥션 풀을 사용하게 될거임. 뭐 그렇긴 한데, 저렇게 다양한 방법이 있으니 사용법이 같은 커넥션을 얻어오는거라도 조금씩 사용 방법이 다를 수 있음. 그래서 커넥션 획득을 추상화 했는데, DataSource로 추상화 함. 저런 커넥션 풀 라이브러리나 DriverManager중에 DataSource를 상속받아 만든 게 있음. 그렇기 때문에, 우리가 여러 커넥션 풀 라이브러리를 쓰고 싶다면, 그냥 저 DataSource라는 인터페이스에 의존하도록 로직을 작성하면 된다. 이 인터페이스는 결론적으로 커넥션을 얻는 것에 집중된 인터페이스이다.