#Spring Boot

스프링의 @Transactional 애노테이션 하나면 트랜잭션을 쉽게 다룰 수 있다고 생각했는데, 실무에서 쓰다 보니 생각보다 고려할 게 많았다. 프록시가 어떻게 동작하는지, 전파 규칙은 어떻게 설정해야 하는지, JPA와는 어떻게 맞물리는지 등등... 그래서 트랜잭션의 기본 개념부터 스프링이 내부적으로 어떻게 처리하는지까지, 실무에서 마주쳤던 내용들을 정리해봤다. 트랜잭션은 데이터베이스에서 데이터의 일관성과 원자성(Atomicity) 을 보장하기 위한 최소 작업 단위다. 스프링은 이 트랜잭션 개념을 추상화해서, 개발자가 데이터베이스

파일 업로드 다운로드를 개발하다 보면 내가 개발하고 있는 어플리케이션이 파일이 저장되는 종착지가 아닐때가 있다. 예를들어 하나의 백엔드 어플리케이션이 모든 도메인을 처리하고 있고 그중에 파일 관련된 핸들링도 포함되어있다면 그 백엔드가 파일 시스템 어딘가에 저장하거나 S3 스토리지로 보낸다. 그런데 마이크로서비스가 보편화된 시대에서 파일이 여러 서비스를 거쳐야 파일 핸들링을 하는 서비스에 도달하는 경우가 있을 수 있다. 그 역할을 클라우드 플랫폼에 포함된 API 게이트웨이가 아니라 Spring Framework로 만들어진 WAS가 해

1편의 업로드 기능을 구현했다면 2편에서는 다운로드를 위한 Controller 와 리소스를 가지고오는 부분에 대해서 설명하겠다. 전편에서 업로드를 구현하기 위해 Multipart 를 사용했다면 이번 편에서는 파일 식별자로 어떻게 파일을 특정하고 응답으로 파일을 내려줄 수 있는지 구현해본다. 바이너리는 org.springframework.core.io.Resource 를 통해 응답을 내려주는것이 특징이다. 컨트롤러부터 보자. 컨트롤러에서 파일을 내려 줄 때 두가지 유형이 있다. 웹 브라우저에서 다운로드 속성을 갖는 응답 이미지 같이

이번에도 전편의 인기에 의해 불려나온 후속편이다. 지난번 아무것도 모르던 시절, 아파치의 commons-io 를 활용해 CommonsMultipartResolver 로 구현했다. 이번에는 스프링의 MultipartFile 를 이용해 파일 업로드 기능을 구현해보겠다 (현재 개인 프로젝트에 이 방식을 사용중) 아울러 김영한 강사님의 스프링 MVC 강의에 이같은 내용이 많기 때문에 이번에는 파일을 서빙하고 저장하고 관리되는 관점에서 글을 더 풀어보겠다. 이 글을 작성하는 시점에서 스프링6가 정식으로 나와있는데 아파치의 commons-io

🫠 실패에 대한 짧은 결론 : 레디스는 인메모리 DB로써 빠른 IO를 요구하는 작업에 최적화 되어있다. 예를 들면 세션 클러스터링이나 캐싱에 많이 사용된다. 그러나 Entity를 계층 구조로 만들고 깊은 내부의 있는 필드에 Document나 RDB 하듯 LIKE 쿼리를 구현하는 것은 바람직하지 않아보인다. 물론 단순한 구조의 Entity에 id필드를 지정하고 id를 가지고 직렬화/역직렬화 하는 것은 가능하다. 결론적으로 key로 value에 바로 접근할 수 있는 Set이나 Hash구조 일 때 의미가 있어보인다. 웹 기반의 채팅 프

웹 어플리케이션을 위한 Spring MVC (블로킹)과 Spring WebFlux(넌블로킹) 방식이 있음 물론 Spring MVC안에서도 @Async 어노테이션으로 비동기 처리를 활성 할 수 있으나 Filter, Interceptor 자체가 동기 처리라 엄청난 성능 향상은 없음 Spring WebFlux에도 Spring MVC와 마찬가지로 @Controller 어노테이션이 있있음. Spring MVC와 큰 차이라면 스트림을 위해 반환에 Mono, Flux를 사용. Spring MVC 는 톰캣 서블릿을 사용하는 프레임워크 고 WebF

Reference 일단 오류와 상관없이.. SimpleJdbcInsert를 빈으로 만드는건 뭔가 이상한듯 저게 저 Repository에서만 쓸텐데.. 저걸 빈으로 만들어서 얻는 이점이 없음 JDBC 드라이버에서 제공해주는 DB 메타데이터를 사용해서 insert 쿼리 정보로 사용한다던데 왠지 빈으로 등록 시점에 JDBC 연결이 완료되지 않았을수도 있겠다 여튼, Entity 객체에서 리플렉션으로 '타입'정보를 꺼내쓴다면 애초에 dataSource같은게 필요없겠지 (순수 Java 리플렉션만으로 될테니) 근데 DataSource를 요구한다

두 요청의 mapping이 주소가 같으나 RequestMethod가 GET과 POST로 구분 되는것을 알 수 있다. HTML은 POST와 GET방식만 지원하고 PUT, DELETE는 지원하지 않는다. 스프링에서 POST와 GET방식을 이용해 나머지 두가지를 사용할 수 있는 기능을 지원하는데 HiddenHttpMethodFilter가 있다. 스프링 2.1이상에서는 자동으로 필터가 등록된다. HiddenHttpMethodFilter는 _method속성의 파라미터가 존재할 경우 그 값을 요청 방식으로 사용한다. 스프링 부트 2.2부터 기