Mi_Q Kingdom

DB 커넥션 풀

- WAS(웹 컨테이너) 실행 되면서 DB와 미리 커넥션을 해놓은 객체들을 Pool에 저장.
  클라이언트가 요청이 오면 커넥션 빌려주고, 처리가 끝나면 다시 커넥션 반납.

- 매번 사용자가 요청할 때 마다 드라이브를 로드하고
  커넥션 객체를 생성 연결하고 종료하면 비효율적이라 DBCP(커넥션 풀)을 사용.



1. 웹 컨테이너(WAS) 실행 되면서 커넥션 객체를 미리 풀에 생성.

2. HTTP 요청에 따라 풀에서 커넥션 객체를 가져다 쓰고 반환.

3. 위와 같은 방식으로 물리적 데이터베이스 커넥션 부하를 줄이고 연결 관리.

4. 풀에 미리 커넥션이 생성되어 있기 때문에 연결 시간이 소비 되지 않음.

5. 커넥션을 계속 재사용하기 때문에 생성 커넥션 수를 제한적으로 설정.




참조 : https://linked2ev.github.io/spring/2019/08/14/Spring-3/

MS-SQL DB 쿼리 내 락
- 테이블 조회 시 행렬은 일시적으로 락이 걸리고 트랜잭션(작업 단위)이 끝날 때 까지 데이터 수정이 불가.
- 무효화. 연산 처리 중 오류 발생 시 트랜잭션은 중단되고 처음 상태로 대기.

락 문제
메인 스레드 외 백그라운드 스레드에서 사용하다 스레드 간 락 잡는 시점이 겹치면 문제 발생.

DB 발생 원인
Create, Update, Delete 를 하면 배타 락 잡힘.
C.U.D. 에서 쓰기를 한꺼번에 하는 트랜잭션 발생 시 배타 락을 오래 잡는다.

락 상태

※ 쿼리 락이 되었다면. (언락 X)
타 유저가 DB를 선점해 사용 중 이거나, 정상적으로 종료 되지 않아 나타나는 현상.

해결법
SQL> EXEC SP_LOCK   -- 락 컬럼 SPID 조회.
SQL> EXEC DBCC InputBuffer( [SPID] )   -- 락 쿼리 확인 OR EXEC SP_WHO [SPID] 유저 정보 확인.
SQL> KILL [SPID]   -- 강제 종료.

DB Lock 예
- 여러 스레드에서 1개 DB instance만 가지고 쓰기 진행 -> X
- 여러 스레드에서 각각 DB instance를가지고쓰기진행 -> O
- 1개의 스레드에서 1개의 instance를 가지고 계속 쓰기하고, 여러 스레드에서 각각 인스턴스 읽기 진행 -> O
- 여러 스레드에서 각각 인스턴스 읽기만 한다. -> X
- 1개 DB instance를 가지고 쓰기 트랜잭션과 읽기를 동시 진행 -> X



참조 : https://programmingfbf7290.tistory.com/entry/SQLite
https://syujisu.tistory.com/193 

MS-SQL 트랜잭션(작업 단위) 동작 방식.

1. Deferred
락을 뒤로 미룬다.
트랜잭션 시작 때 락을 잡지 않다가 읽기 작업이 있으면 공유 락을 잡고 쓰기 작업이 있다면 예약 락을 잡는다.
즉, 락이 뒤로 미뤄지기 때문에 다른 스레드에서 DB 작업이 가능.

2. Immediate
트랜잭션을 시작할 때 예약 락이 잡힌다.
다른 스레드에서 읽기는 가능하나 예약 락은 1개만 가능해 다른 Immediate 트랜잭션 시작 불가.

3. Exclusive
트랜잭션을 시작할 때 배타 락이 잡힌다.
트랜잭션 처음부터 끝까지 다른 스레드 DB 작업 불가.

 


※ 안드로이드에서는 Immediated, exclusive 동작 방식만 지원
Exclusive 동작 방식 보다 Immediate 권장.
기본적으로 안드로이드는 Exclusive 방식 지원.
따라서, db.beginTransaction() 보다 Immediate 동작 방식인 db.beginTransactionNonExclusive() 권장.
DB 락 문제 조금 이나마 회피 가능.

참조 : https://programmingfbf7290.tistory.com/entry/SQLite