Spring DB Part 1 – 데이터 액세스의 기본 원칙 요약

Spring DB Part 1 – 데이터 액세스의 기본 원칙 요약

김영한의 Spring DB Part 1 – Core Principles of Data Access를 충실히 따르고 내용을 요약하였다.

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-1/dashboard

정보 정리

1. JDBC의 이해

JDBC란? Java 데이터베이스 연결의 약어입니다. Java 프로그램이 데이터베이스에서 데이터를 보내고 받을 수 있도록 하는 인터페이스입니다. JDBC가 존재하지 않고 개발자가 데이터베이스를 교체하면 해당 데이터베이스를 사용하는 모든 응용 프로그램 코드도 교체해야 합니다. 하지만 JDBC 등장 이후 상용 코드는 각 벤더가 인터페이스에 따라 구현했기 때문에 기술의 영향을 받지 않는다.

2. 연결 풀 및 데이터 소스 이해

연결이 설정된 경우에만 데이터베이스에서 데이터를 검색할 수 있습니다. 그러나 연결을 얻는 것은 비용이 많이 듭니다. DB에 접근할 때마다 새로운 커넥션을 생성한다면 다음 과정을 계속 진행해야 합니다.

Application Code는 Driver에 연결 요청 -> DB Driver는 DB와 TCP/IP 3-way Handshake 수행 -> DB에 ID/PASSWORD 제공 -> DB는 인증 과정 후 세션 생성 및 응답 완료 -> Driver는 연결 Application에 다시 Code로 연결

이것은 매우 비효율적이기 때문에 약 10개의 사전 배선 연결을 포함합니다. 이것은 연결 풀입니다.

다양한 방법이 있습니다. B. 다른 연결 풀을 사용하거나 드라이버를 통해 연결합니다. DataSource는 그것의 추상화입니다.

3. 트랜잭션 이해

트랜잭션은 데이터의 상태를 변경하는 논리적 엔터티입니다. ACID를 충족해야 합니다.

트랜잭션에는 다음과 같은 격리 수준이 있습니다.

  1. 무제한 읽기
  2. 의무 사항을 읽으십시오
  3. 반복 읽기
  4. SERIALIZABLE (직렬화 가능)

높을수록 격리는 나빠지지만 동시성은 더 좋아집니다.

각 단계의 내용은 다음과 같습니다. (이 부분에 대해서는 강의에서 자세히 다루지 않습니다)

1. 커밋되지 않은 읽기는 트랜잭션이 커밋되지 않은 경우에도 세션에 등록된 값을 읽을 수 있음을 의미합니다.

2. 커밋된 값만 읽을 수 있음

3. 자기보다 작은 거래번호의 값만 보인다.

4. SELECT 쿼리도 잠급니다.

4. Spring 문제 해결 – 트랜잭션

이것은 아마도 다루어야 할 가장 중요한 부분 일 것입니다.

트랜잭션이 발생하는 첫 번째 위치는 DAO를 회사에 바인딩하는 서비스 레이어인 것 같습니다.

트랜잭션은 서비스 계층에 적용되며, 추상화된 기술이 사용되지 않는 한 특정 기술은 애플리케이션 코드와 밀접하게 결합됩니다.

기술이 JDBC에서 JPA로 변경되더라도 애플리케이션 코드는 순수한 Java 코드로 유지되어야 합니다. 그러나 JDBC와 JPA는 트랜잭션 로직이 다릅니다. 어떻게 해결할 수 있습니까?

답은 봄에 있다. 봄은 PlatformTransactionManager 또한 지속적으로 DAO에 연결을 전달해야 하는 문제를 해결합니다. 트랜잭션 관리자 연결 트랜잭션 동기화 관리자라는 곳에 저장

각 DAO는 서비스에서 연결을 가져오는 것이 아니라 트랜잭션 동기화 관리자에서 직접 연결을 가져옵니다.

연결은 스레드 로컬이라는 위치에 유지되므로 스레드로부터 안전합니다.

이렇게 하면 단순히 PlatformTransactionManager 구현체를 대체함으로써 애플리케이션 코드를 변경하지 않고 기술을 변경할 수 있습니다.

TransactionTemplate을 사용하여 좀 더 깔끔하게 만들 수 있습니다. 트랜잭션을 시작, 커밋 및 롤백하는 코드를 템플릿으로 작성하고 비즈니스 로직을 콜백으로 포함하기만 하면 됩니다.

그러나 여전히 응용 프로그램 코드에는 트랜잭션이라는 기술 코드가 있습니다.

이를 제거하기 위해 @Transactional을 사용합니다. 적절한 주석이 첨부되면 Spring의 빈 후처리가 자동으로 프록시 클래스를 생성하고 트랜잭션 관련 논리를 추가합니다.

그리고 Spring Boot는 기본적으로 DataSource와 PlatformTransactionManager를 bean으로 자동 등록합니다.

결국 최종 흐름은 다음과 같습니다.


5. Java 예외 이해

DAO는 현재 JDBC이지만 SQLException은 체크 예외이므로 비즈니스 로직은 JDBC에 의존합니다.

먼저 확인된 예외와 확인되지 않은 예외를 살펴보겠습니다.

컴파일러가 오류를 발생시키지 않도록 확인된 각 예외를 포착하거나 발생시켜야 합니다. 반대로 확인되지 않은 예외는 포착하거나 버려서는 안 됩니다.

활성화된 예외는 상위 코드를 하위 코드에 종속시킵니다.

비즈니스 관점에서 매우 중요하여 확인해야 하는 항목에 대해서만 확인 예외를 만듭니다. 사실 이것은 거의 발생하지 않습니다. 따라서 대부분의 경우 확인되지 않은 예외를 사용할 수 있습니다.

이 경우 예외를 변환할 때 기존 예외를 포함해야 합니다. 그렇지 않으면 이전 예외에 대한 스택 추적이 사라집니다.

6. Spring으로 문제 해결 – 예외 처리, 반복

DB별로 발생하는 에러 코드가 다릅니다. 따라서 mysql을 기반으로 코드를 catch하여 예외를 처리했다면 데이터베이스가 Oracle로 변경될 때 새 코드를 catch하기 위한 로직을 모두 변경해야 합니다.

이 때문에 Spring은 각 db 예외를 추상화하고 배포합니다.

Spring에서 제공하는 예외 중 최상위는 DataAccessException입니다. 그리고 RuntimeExcetpion을 상속합니다.
그 시점에서 다시 시도하면 성공할 수 있는 예외로 일시적인 예외가 있고 성공할 수 없는 예외로 비일시적 예외가 있습니다.

SQLExceptionTranslator는 예외를 포착하고 각 DB의 오류 코드를 구문 분석하고 DataAccessException으로 변환됩니다. 유형은 DataAccessException이지만 자세히 보면 코드에 맞는 예외를 반환합니다.

따라서 각 제공자로부터 응답하는 코드를 수동으로 구문 분석할 필요가 없습니다. SQLExceptionTranslator는 이를 구문 분석하고 적절한 예외를 리턴합니다.

내용 자체가 단순해서 강의를 듣는데 큰 어려움은 없었습니다. 출퇴근길, 주말, 퇴근길에 대중교통에서 들었기 때문에 일주일 정도 지속된 것 같아요.

그래도 평소에 잘 모르는 부분을 체크해서 누가 물어봐도 알려줄 수 있도록 정리한 것 같습니다.

강의 구매 여부를 고민하시는 분들은 위의 요약을 참고하시면 구매 결정에 도움이 될 것입니다.