2022-06-28 TIL

Transaction Isolation

• READ UNCOMMITED: 커밋되지 않은 읽는다.
• READ COMMITED: 커밋된 데이터만 읽는다.
• REPETABLE READ: 자신의 트랜잭션이 생성되기 이전의 트랜잭션(낮은 번호의 트랜잭션)의 커밋된 데이터만 읽는다.
• SERIALIZABLE: Lock 걸고 사용.
• DEFAULT: 사용하는 DB 기본 설정을 따른다. (ORACLE은 READ_COMMITED, MySQL InnoDB는 REPETABLE_READ)

Commit

auto commit 모드에서 manual commit 모드로 전환하는 것을 트랜잭션을 시작한다고 관례적으로 표현한다.

DB Connection

애플리케이션에서 DB 트랜잭션을 사용하려면 트랜잭션을 사용하는 동안 같은 Connection을 유지해야 한다. 그래야 같은 세션을 사용할 수 있다.

Exception

김영한님 스프링 DB 2편 - 데이터 접근 핵심 원리 강의를 기반으로 정리한 내용입니다.

예외에 대해서는 2가지 기본 규칙을 기억할 것

1. 예외는 잡아서 처리하거나 던져야 한다.
2. 예외를 잡거나 던질 때는 지정한 예외뿐만 아니라 그 자식들드 함께 처리된다.
   • 예를 들어서, Exception을 catch로 받으면 그 하위 예외들도 전부 잡을 수 있다.
   • 예를 들어서, Exception을 throws Exception으로 던지면 그 하위 예외들도 모두 던질 수 있다.

참고: 예외를 처리하지 못하고 계속 던지면 어떻게 될까?

• Java main() 쓰레드의 경우에는 예외 로그를 출력하면서 시스템이 종료된다.
• 웹 애플리케이션의 경우 여러 사용자의 요청을 처리하기 때문에 하나의 예외 때문에 시스템이 종료되면 안 된다. WAS가 해당 예외를 받아서 처리하는데, 주로 사용자에게 개발자가 지정한 오류 페이지를 보여준다.

  class Controller {
    .
    .
    .

    public void request() throws SQLException, ConnectException {
      service.executeBusinessLogic();
    }
  }

  class Service {
     .
     .
     .

    public void executeBusinessLogic() throws SQLException, ConnectException {
      repository.call();
      networkClient.call();
    }
  }

throws SQLException, ConnectException처럼 예외를 던지는 부분을 코드에서 선언하는 것이 왜 문제이띾? 바로 서비스, 컨트롤러 단에서 java.sql.SQLException을 의존하기 때문에 생긴다. 향후 Repository를 JDBC 기술이 아닌 다른 기술로 변경한다면, 그래서 SQLException이 아니라 예를 들어, JPAException으로 예외가 변경된다면 SQLException에 의존하는 모든 Service, Controller 코드를 JPAException에 의존하도록 고쳐야 한다. Service나 Controller 입장에서는 어차피 본 계층에서 처리할 수 없는 예외를 의존한다는 점에서 큰 비효율성이 발생한다(SQL 쿼리 문제나, 네트워크 문제를 Service나 Controller 단에서 해결할 방법이 있나?). 결과적은 OCP(Open-Close-Principle), DI를 통해 클라이언트 코드의 변경 없이 대상 구현체를 변경할 수 있다는 스프링의 장점이 CheckedException 때문에 발목을 잡히게 된다.