필기노트

1. 비즈니스 로직과 트랜잭션(Service) 트랜잭션은 비즈니스 로직이 있는 서비스 계층에서 시작해야 한다. 비즈니스 로직이 잘못되면 해당 비즈니스 로직 으로 인해 문제가 되는 부분을 함께 롤백해야 하기 때문이다. 그런데 트랜잭션을 시작하려면 커넥션이 필요하다. 결국 서비스 계층에서 커넥션을 만들고, 트랜잭션 커밋 이후에 커넥션을 종료해야 한다. 애플리케이션에서 DB 트랜잭션을 사용하려면 트랜잭션을 사용하는 동안 같은 커넥션을 유지해야한다. 그래야 같 은 세션을 사용할 수 있다. 2. 커넥션과 세션(Repository) 애플리케이션에서 같은 커넥션을 유지하려면 어떻게 해야할까? 가장 단순한 방법은 커넥션을 파라미터로 전달해서 같은 커넥션이 사용되도록 유지하는 것이다. 3. Service 트랜잭션 적용 ..

1. 커넥션 풀 이해 1) 데이터베이스 커넥션을 매번 획득 커넥션을 새로 만드는 것은 과정도 복잡하고 시간도 많이 많이 소모되는 일이다. 이런 문제를 한번에 해결하는 아이디어가 바로 커넥션을 미리 생성해두고 사용하는 커넥션 풀이라는 방법이다. 2) 커넥션 풀 초기화와 연결 상태 애플리케이션을 시작하는 시점에 커넥션 풀은 필요한 만큼 커넥션을 미리 확보해서 풀에 보관한다. 기본값은 보통 10개이다. 실무에서는 항상 기본으로 사용한다. 커넥션 풀에 들어 있는 커넥션은 TCP/IP로 DB와 커넥션이 연결되어 있는 상태이기 때문에 언제든지 즉시 SQL을 DB에 전달할 수 있다. 3) 커넥션 풀 사용 애플리케이션 로직에서 이제는 DB 드라이버를 통해서 새로운 커넥션을 획득하는 것이 아니다. 이제는 커넥션 풀을 통..

1. JDBC 표준 인터페이스 JDBC(Java Database Connectivity)는 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API다. JDBC 는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다. - 위키백과 대표적으로 다음 3가지 기능을 표준 인터페이스로 정의해서 제공한다. java.sql.Connection - 연결 java.sql.Statement - SQL을 담은 내용 java.sql.ResultSet - SQL 요청 응답 자바는 이렇게 표준 인터페이스를 정의해두었다. 이제부터 개발자는 이 표준 인터페이스만 사용해서 개발하면 된다. 그런데 인터페이스만 있다고해서 기능이 동작하지는 않는다. 이 JDBC 인터페이스를 각각의 DB 벤더(회사)에서 자신 의 DB에 맞도록..

1. API 오류 API는 각 시스템 마다 응답의 모양도 다르고, 스펙도 모두 다르다. 예외 상황에 단순히 오류 화면을 보여주는 것이 아니라, 예외에 따라서 각각 다른 데이터를 출력해야 할 수도 있다. 그리고 같은 예외라고 해도 어떤 컨트롤러에서 발생했는가에 따라서 다른 예외 응답을 내려주어야 할 수 있다. 한마디로 매우 세밀한 제어가 필요하다. 결국 지금까지 살펴본 BasicErrorController 를 사용하거나 HandlerExceptionResolver 를 직접 구현하는 방식으로 API 예외를 다루기는 쉽지 않다. 스프링은 API 예외 처리 문제를 해결하기 위해 @ExceptionHandler 라는 애노테이션을 사용하는 매우 편리한 예외 처리 기능을 제공하는데, 실무에서 API 예외 처리는 대부..

1. 주식 1) 분산투자 김승호 회장은 이미 사업체 소득으로 자산을 형성했기 때문에 잃지 않는 분산투자를 추구한다. 주식, 채권, 예금, 금, 비트코인 등 서로 반대로 움직이는 자산들에 자금을 분산하는 행위를 말한다. 서로 반대로 움직이는 자산을 운용하면 리벨런싱 투자를 할 수 있다. 당연한 이야기지만 성공한 몰빵투자보다는 수익률이 떨어진다. 분산투자의 핵심목적은 “잃지 않는 것”이다. 월적립식으로 투자기간까지 나누면 일반적인 분산투자로는 충분하다. 2) 주식 투자에서 성공하는 사람들은 크게 세 가지 특징을 갖고 있다. (1) 경영자와 같은 마음으로 시장에서의 회사 역할을 이해한다. 단 한 주만 갖고 있어도 당신은 사주다. 그러니 사주의 마음을 갖고 회사를 공부하고 살펴야 한다. 대표이사, 즉 회사의 사..

1. 서블릿 예외 처리 웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 애플리케이션에서 예외가 발생했는데, 어디선가 try ~ catch로 예외를 잡아서 처리하면 아무런 문제가 없다. 그런데 만약에 애플리케이션에서 예외를 잡지 못하고, 서블릿 밖으로 까지 예외가 전달되면 어떻게 동작할까? 1. 정상 요청 WAS(/error-ex, dispatchType=REQUEST) -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러 2. 예외발생 WAS(여기까지 전파) 컨트롤러(/error-page/500) -> View WAS는 오류 페이지 경로를 찾아서 내부에서 오류 페이지를 호출한다. 이때 오류 페이지 경로로 필터, 서블릿, 인터셉터, 컨트롤러가 모두 다시 호출된다..

목차 1. 공통 관심 사항 2. 필터 3. 스프링 인터셉터 4. ArgumentResolver 활용 1. 공통 관심 사항 로그인 되지 않은 사용자는 상품 관리 뿐만 아니라 미래에 개발될 페이지에도 접근하지 못하도록 하자. 이렇게 애플리케이션 여러 로직에서 공통으로 관심이 있는 있는 것을 공통 관심사(cross-cutting concern)라고 한다. 이러한 공통 관심사는 스프링의 AOP로도 해결할 수 있지만, 웹과 관련된 공통 관심사는 지금부터 설명할 서블릿 필터 또는 스프링 인터셉터를 사용하는 것이 좋다. 웹과 관련된 공통 관심사를 처리할 때는 HTTP의 헤더나 URL의 정보들이 필요한데, 서블릿 필터나 스프링 인터셉터는 HttpServletRequest 를 제공한다. 2. 필터 1) 필터 흐름 로그인..

1. 직접 개발한 세션의 내부구조 @Component public class SessionManager { public static final String SESSION_COOKIE_NAME = "mySessionId"; private Map sessionStore = new ConcurrentHashMap(); /** * 세션 생성 */ public void createSession(Object value, HttpServletResponse response) { //세션 id를 생성하고, 값을 세션에 저장 String sessionId = UUID.randomUUID().toString(); sessionStore.put(sessionId, value); //쿠키 생성 Cookie mySessionC..

목차 1. 검증 요구사항 2. Bean Validation 3. @Validated 4. Form 전송 객체 분리 5. Bean Validation - 에러 메시지 6. Bean Validation - 오브젝트 오류 7. BindingResult 8. 오류 코드와 메시지 처리 1. 검증 요구사항 클라이언트 검증은 조작할 수 있으므로 보안에 취약하다. 서버만으로 검증하면, 즉각적인 고객 사용성이 부족해진다. 둘을 적절히 섞어서 사용하되, 최종적으로 서버 검증은 필수이다. API 방식을 사용하면 API 스펙을 잘 정의해서 검증 오류를 API 응답 결과에 잘 남겨주어야 한다. 고객이 상품 등록 폼에서 상품명을 입력하지 않거나, 가격, 수량 등이 너무 작거나 커서 검증 범위를 넘어서면, 서버 검증 로직이 실패해..

1. 메시지 악덕? 기획자가 화면에 보이는 문구가 마음에 들지 않는다고, 상품명이라는 단어를 모두 상품이름으로 고쳐달라고 하면 어떻게 해야할까? 여러 화면들을 다 찾아가면서 모두 변경해야 한다. 화면이 수십개 이상이라면 수십개의 파일을 모두 고쳐야 한다. 왜냐하면 해당 HTML 파일에 메시지가 하드코딩 되어 있기 때문이다. 이런 다양한 메시지를 한 곳에서 관리하도록 하는 기능을 메시지 기능이라 한다. 스프링 부트를 사용하면 스프링 부트가 MessageSource 를 자동으로 스프링 빈으로 등록하고, 메시지 소스는 messages 라는 이름으로 기본 등록된다. 따라서 messages_en.properties , messages_ko.properties , messages.properties 파일만 등록하면..