Tomcat 서버 구조 디버깅 모드로 찾아본 결론 초기 접속 시 세션 확인 초기 접속 시, 세션 확인 사용자 요청은 각 Port에 맞게 Adapter를 통해 들어온다. 이 때, Request / Response 객체는 각각 생성된다. 그리고 해당 Adapter에서 Request 객체에 SessionId가 발급되어 등록됨. Catalina 엔진에서 세션을 요청함. 이 때, Context.getManager()를 통해 요청한다. Context는 Servlet Container(Tomcat)이고, Manager는 ManagerBase다. ManagerBase에서 현재 Request 객체가 가진 SessionID로 저장된 Session이 있는지 확인한다. 없으면 Null이 반환되고, 있으면 Session이 반환..
이 글은 인프런 김영한님의 강의를 복습하며 작성한 글입니다. 데이터 접근 예외 직접 만들기 앞선 게시글에서는 DB를 접근하면서 발생할 수 있는 체크 예외를 런타임 예외로 감싸는 방법으로 서비스 계층으로 DB 예외가 누수되는 것을 방지했다. 그렇지만 DB 계층에서 발생할 수 있는 특정 예외들 중 일부는 서비스 계층에서 복구 시도를 해볼 수 있다. 예를 들어 회원 가입 시, DB에 이미 같은 ID가 있어 유니크 제약 조건에 걸려서 예외가 발생한다고 가정해보자. 이 때, 서비스 계층으로 예외가 올라오면 서비스 계층은 이 ID 뒤에 숫자를 붙여 새로운 ID를 만들어 다시 한번 저장을 시도해볼 수 있을 것이다. 즉, Repository 계층에서 발생할 수 있는 예외를 서비스 계층에서 복구를 해주는 것이다. 데이터..
이 글은 인프런 김영한님의 강의를 복습하며 정리한 글입니다. 체크 예외 서비스 계층은 가급적 특정 구현 기술에 의존하지 않고, 순수한 자바 코드로 작성되는 것이 좋다. 이렇게 하려면 예외에 대한 의존 문제도 해결해야한다. 예를 들어 위의 코드를 볼 수 있다. 위는 MemberServiceV3_3 코드인데, 메서드에 "throws SQLException'이 있는 것을 확인할 수 있다. @Transcational을 이용해 트랜잭션 추상화로 DB 기술 의존성을 해결한 것으로 이해를 했으나, 사실은 SQLException이 남아있기 때문에 아직까지 DB 기술에서 자유롭지는 않다. 앞서 배웠던 예외들을 살펴보면 이 SQLException은 Service 계층에서 처리할 수 없는 문제다. 즉, 서비스 계층이 신경쓰..
이 글은 인프런 김영한님의 강의를 복습하며 작성한 글입니다. 예외 전환 시, 기존 예외 체크 예외를 런타임 예외로 바꾼다면, 반드시 기존 예외를 포함해야한다. 기존 예외를 포함하지 않으면 Stack Trace에서 어떤 문제 때문에 실제 예외가 발생했는지 확인할 수 있는 방법이 없어진다. 코드 실습 (StackTraceTest.java) 체크 예외를 런타임 예외로 변경할 때, 체크 예외를 런타임 예외로 반드시 한번 더 감싸준다. 그렇게 해야지만 StackTrace에서 예외 히스토리를 정상적으로 확인할 수 있다. Repository static class Repository{ public void call() { try { runSQL(); }catch (SQLException e){ // 예외를 포함한다 ..
이 글은 인프런 김영한님의 강의를 복습하며 작성한 글입니다. 체크 예외와 언체크 예외는 언제 사용하지? 내가 고려해야 할 수많은 문제 100개가 있다고 가정해보자. 이 때, 이 문제를 모두 해결하기 위한 방법은 하나씩 모든 문제를 처리하는 방법이 있을 것이다. 또 다른 방법은 대원칙을 하나 정하고, 그 대원칙에서 벗어나는 문제들을 하나씩 처리하는 방법이 있을 것이다. 개발자 입장에서는 후자의 방법이 더 좋다. 앞으로 예외를 처리할 때는 다음과 같이 처리하자! 기본적으로 런타임 예외를 사용한다. 런타임 예외를 잘 사용하기 위해 Document에 잘 정리한다. 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용한다. 그렇다면 어떤 경우가 체크 예외를 사용하는 예시일까? 계좌 이체 실패 예외 → 비즈..