Spring JPA 를 통해 DB에 테이블을 만들고 컬럼으로 HashMap 을 지정할 경우 어노테이션을 통해서 따로 추가적인 정의를 해줘야 한다. 실제 실무에서 사용되는 코드를 살펴보던 중 Map 타입의 데이터를 저장하는 테이블을 발견했는데 컬럼의 정의가 "nvarchar"로 정의되어 있었다. 나는 그 이유가 bulk insert를 위한 명시적 columnDefinition 인 줄 알았으나 잘못 된 생각이었다. 우선 varchar와 nvarchar 의 차이를 살펴보자. varcher nvarchar 형태 가변길이 문자열 저장 영어 1byte 2byte 한글 2byte 인코딩 iso_1 유니코드 둘의 중요한 차이는 인코딩 방식이 다르다는 것이다. 컴퓨터의 기본 저장 단위는 1바이트로 8bit를 사용하게 된..
자바 Reflection 기능. 특정 DB 테이블을 csv 파일로 변환하는 도중 테이블의 필드 정보를 사용해야 할 경우 Reflection 기능을 통해서 확인 할 수 있다. Spring JPA를 사용하다 보니 DB 테이블을 직접 생성하지 않고 @Entity 어노테이션을 통해서 생성을 하면 자바의 Reflection 기능을 통해 쉽게 테이블의 컬럼 정보 (Class 정보)를 가져올 수 있는 것이다. 기능확인을 위해 Reflection 이라는 클래스를 만들었다. @NoArgsConstructor @AllArgsConstructor @Entity public class Reflection { @Column(name = "integer_num") private Integer integerNum; @Setter ..
BlockingQueue가 사용된 코드를 보면서 가장먼저 확인해 봐야 했던 부분은 생산자 소비자 패턴이다. (모든 경우가 위와 같은 경우가 될 수는 없지만 일반적인 구조는 위와 같은 형태) 멀티 쓰레드 환경이나 혹은 다양한 부분에서 높은 비율의 공통 사용 로직이 있다고 가정할 때 과부하를 막기위해서 어떠한 조치를 해야한다. 이 문제해결을 위해서 나온 것이 바로 생산자 소비자 패턴인데 공통적으로 수행해야 할 Task를 중심으로 작업을 생산해 내는 생산자(Producer)와 작업을 처리하는 부분인 소비자(Consumer)의 형태로 나눠서 부하를 조절하겠다는것이고 생산된 작업 Task 는 Queue라는 공통 자원을 통해 관리, 생산자와 소비자의 역할을 분리시키자는 개념이다. 분리된 생성자와 소비자는 각각의 ..
개발 공부를 할 때 작은 프로젝트단위에서만 개발을 해서그런지 if else 문을 많이 사용하긴 했지만 switch case 문은 한 번도 사용해 본 적이 없었다. 굳이 사용을 할 필요성이 없었기 때문이다. 그러다 최근 실무에서 패킷 분석을 하던 도중 switch case 문이 많은 곳에서 사용된다는 것을 확인했고 문뜩 if else 문과 비교분석을 통해서 정리를 해봐야 겠다는 생각이 들었다. 우선 구글을 돌아다녀서 확인 한 결과 가장 많이 나온 얘기는 if else 와 switch case 둘 모두 전체 프로그래밍의 성능에 큰 차이가 없기 때문에 의미에 따라 사용하는것이 좋다는 것이다. 물론 switch case 를 통해서 나타낼 수 없는 경우에는 당연히 if else를 사용하겠지만 둘 모두의 문법에서 ..
혼자 공부할 때는 해시코드를 이용해서 값을 생성할 경우가 없었는데 실제 실무에서 확인해보면 해시코드를 사용해서 키 값을 만들어 내는 경우가 있었다. 해시코드를 공부하던 도중 Objects.hash 함수와 Objects.hashCode 함수 값을 통해서 해시코드를 생성할 수 있다는 것을 알았는데 그럼 둘의 차이는 무엇일까? 위와 같이 null 값, 0 값 그리고 0이 아닌 다른 수를 통해서 hash 값을 생성한 결과 아래와 같은 결과를 얻을 수 있었다. Objects.hashCode() 의 경우 null값 과 0의 결과 값이 0으로 모두 동일했고 Objects.hash() 의 경우 null 값이 0값의 해시값과 동일한 결과를 보여줬다. 또 두 함수의 차이점은 0과 null이 아닌 다른 값을 집어 넣더라도 ..
스프링 인터셉터: 서블릿 필터와 같이 웹과 관련된 공통사항을 처리하는 방법 (Spring MVC가 제공하는 기능이고 서블릿 필터보다 훨씬 더 많은 기능들을 제공한다) 스프링 인터셉터 기본 흐름 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러 로그인 사용자일 경우 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러 비 로그인 사용자 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터(적절하지 않은 요청이라 판단, 컨트롤러 호출 X) 스프링 인터셉터는 아래와 같이 3개로 구성이 된다. public interface HandlerInterceptor { default boolean preHandle(HttpServlet..
Spring MVC의 구조 우선 HTTP 요청이 오게되면 핸들러와 핸들러 어댑터를 통해서 컨트롤러를 호출한다. 스프링은 이미 필요한 핸들러 매핑과 핸들러 어댑터를 대부분 구현해 두었기 때문에 개발자가 직접 핸들러 매핑과 핸들러 어댑터를 만드는 일은 거의 없다. 1. DispatcherServlet이 핸들러를 조회해서 핸들러를 매핑한다. HandlerMapping을 순서대로 실행해서 핸들러를 찾는다 2. 핸들러를 처리할 수 있는 핸들러 어댑터를 조회한다. 3. 핸들러 어댑터를 통해서 실제 컨트롤러를 호출한다. 디스패처서블릿이 조회한 핸들러 어댑터를 실행하면서 핸들러 정보도 같이 넘겨주고 그 결과를 반환한다. 애노테이션 기반의 컨트롤러, @RequestMapping 을 처리하는 핸들러 어댑터인 Request..
@RestController VS @Controller 일반석으로 @Contorller 애노테이션을 사용해서 매핑하게 되면 반환 값을 String 으로 했을 때 반환 값 자체를 뷰 이름으로 인식한다. 그래서 뷰를 착고 뷰가 렌더링 되게 되는데 @RestController를 사용해서 반환 값을 String 으로 하게 되면 HTTP 메세지 바디에 반환 String 값을 바디에 바로 입력을 한다. 따라서 실행 결과로 String 메세지를 받을 수 있다. PathVariable을 이용한 GetMapping @GetMapping("/경로/{id}") public String usingPathvariableGetMapping(@PathVariable("id") int id){ //(@PathVariable int ..
MVC 패턴을 사용하기 위해서 여러가지 복잡한 과정들을 거친다. 컨트롤러를 이용해 모델에 데이터를 담아서 뷰로 전달하는 일련의 과정은 여러가지 방식으로 구현될 수 있다. 어떤 프레임워크를 사용하고 어떤 방식으로 사용할지에 따라서 다르게 구현할 수 있지만 현재 스프링 프레임워크를 사용하는 실무에서는 99.9% @RequestMapping 방식의 컨트롤러를 사용한다. @RequestMapping 은 애노테이션 기반의 컨트롤러를 지원하는 핸들러 매핑과 어댑터이다. (RequestMappingHandlerMapping, RequestMappingHandlerAdapter) @Controller: 스프링이 자동으로 스프링 빈에 등록한다. (내부에 @Component 애노테이션이 존재) 스프링 MVC에서 애노테이션..
여러가지 방법들이 있겠지만 다음의 3가지 방법을 주로 사용한다. HTTP 요청 데이터 1. GET 쿼리 파라미터 url을 통해서 메세지 바디 없이 쿼리 파라미터에 데이터를 포함해서 전달한다. 검색, 필터, 페이징등에서 많이 사용하는 방식이다. 2. POST-HTML Form 메세지 바디에 쿼리 파라미터 형식으로 전달한다. 회원 가입, 상품 주문 등을 할 때 사용한다. 3.HTTP message body HTTP API에서 주로 사용하는 방법으로 데이터 형식은 주로 JSON을 사용한다.
