Intro 스프링기반 프로젝트를 만들다 보면 기계적으로 필요에 따라 각종 어노테이션을 붙이게 됩니다. 컨트롤러에는 @Controller를, 서비스 레이어에는 @Service를, 그리고 데이터베이스에 접근하는 퍼시스턴스 레이어에서는 @Repository를 붙였습니다. 그 외 어플리케이션 컨텍스트에 빈으로 등록 하고 싶은데 특별한 설정 절차가 필요 없어서 컴포넌트 스캔을 통한 자동 등록이면 충분 할 때에는 @Component를 붙여 왔습니다. 그런데, 사실 Bean 으로 등록되어 후에 Dependency Injection에 사용된다는 공통점을 생각 해 보았을 때는 "전부 @Component"로 해도 되는거 아니야?" 라는 생각이 들 수 있습니다. 각각의 차이도 모른채 습관적으로만 사용하고 있는게 사실입니다...

Intro 프로젝트에서 파일 업로드 부분에 대한 개선을 진행 했습니다. 기존의 파일 업로드를 처리하는 부분에 몇가지 문제가 있었는데, 특히 대용량 파일을 안정적으로 업로드 하기 위해서 해결해야 하는 포인트들이 여러가지가 있었고, 꽤나 난해했습니다. 사용자가 파일 업로드를 마쳤지만, 서버에서 일어나는 다양한 작업을 마칠때까지 오랜 시간동안 응답을 받지 못함 사용자 입장에서 업로드 100% 에서 오랜시간 화면이 멈추어 있어 UX가 좋지 않음 대용량의 파일을 업로드할 때 응답에 걸리는 시간이 너무 오래걸려 timeout 되는 문제 사용자는 파일을 성공적으로 업로드 했지만, 서버에서 해당 파일을 처리중 문제가 생겼을 때의 방안 대용량의 파일 업로드시 대량의 IO 작업으로 시스템 자원이 쏠리는 현상 간단히 추려보..

Intro 얼마전 코틀린으로 진행중인 토이프로젝트에서 응답속도가 생각만큼 나오지 않기에 쿼리 나가는걸 하나하나 확인 해 보았습니다. 그랬더니 분명 LAZY로 되어있는 여러가지 연관관계들이, 따로 사용하는 곳도 없는데 전부 다 하나씩 Eager Fetch 처럼 불러지는게 확인 되었습니다. 코틀린에서 JPA를 사용하다보면 자바와는 다른 코틀린의 설계로 인해 의도치 않은 문제가 많이 발생 할 수 있는데요. 어떤 문제가 있었는지, 그리고 LAZY 로딩이 의도대로 작동하게끔 하려면 어떻게 해야 하는지에 대해 알아보겠습니다. 필요시 모든 예제 코드는 https://github.com/Shane-Park/helloKotlin/tree/master/jpatest 에서 확인 하실 수 있습니다. 예제 코드 프로젝트 생성 ..

Intro DTO 혹은 VO 객체를 생성 할 때, Immutable 하게 생성 한다면 여러가지 장점이 있습니다. 멀티 쓰레드 환경에서 동기화를 고려 할 필요 없이 안전하게 사용 할 수 있으며, 캐싱을 하기에도 유리합니다. 특히 mutable 객체를 잘못 코딩함으로서 생기는 사이드이펙트는 예측하기도 어려울 뿐더러 오류가 발견되는것도 쉽지 않습니다. 한참이 지나서야 도대체 알 수 없는 오류가 발생해서 이것 저것 한참을 디버깅을 하다가 객체를 잘못 다룬게 발견될때는 거의 소름이 돋을 정도입니다. 프로퍼티의 값이 변화될 일이 없고, 값이 변경되어서는 안되는 객체를 방어적 복사를 하는 거 보다는 애초에 불변객체로 생성 하는것이 성능을 비롯한 여러 가지 장점이 있습니다. 재사용도 얼마든지 할 수 있습니다. 이전의 ..

Intro 스프링부트에서는 아래와 같은 설정으로 간단하게 인메모리 H2 데이터베이스를 사용 할 수 있습니다. application.yml spring: datasource: url: jdbc:h2:mem:testdb username: sa build.gradle.kts runtimeOnly("com.h2database:h2") 이후 h2:console 설정을 켠다면, 콘솔 페이지에서 데이터베이스를 직접 확인 해 볼 수 있는데요 spring: h2: console: enabled: true settings: web-allow-others: true 위와 같이 설정했을때에는, /h2-console 경로로 들어가면 데이터베이스를 웹 페이지에서 직접 확인 해 볼 수 있습니다. 그런데, Test Connectio..