서론 데이터베이스를 이용한다면 대부분 쓰기보다 읽기 의 행위가 더 많습니다. DB의 부하를 줄이기 위해 다음과 같이 Master - Slave 구조를 많이 사용하는데요. 이러한 구조를 가지고 있을 때 Transection의 속성이 readOnly = true 인 경우 Slave 데이터베이스에 Select query 가 발생하게 해야합니다. 따라서 이번 본문에서는 @Transactional(readOnly = true) 인 경우는 Slave DB 접근 @Transactional(readOnly = false) 인 경우에는 Master DB 접근 위의 조건을 만족하기 위한 방법을 Spring-boot 기준으로 소개하고자 합니다. 사전 환경설정 실습 환경은 다른 것은 필요 없고 저는 MySQL 데이터베이스를 ..
서론 스프링 컨트롤러에서 클라이언트로부터 받은 값을 검증하기 위해 Validation을 많이 사용하곤 합니다. JSR 380이 제공해주는 Bean Validation 의 종류는 다양하지만 각자의 서비스에 따라 기본적으로 제공해주는 애노테이션만으로는 검증을 모두 다 지원해주지는 못합니다. 따라서 상황에 따라 각 서비스에 맞는 커스텀한 Validation을 만들어서 활용하기도 합니다. 그렇다면 이번 글에서는 왜 커스텀 Validation을 만들었고 만드는 과정을 소개하고자 합니다. 왜 필요한가? 기존 @NotNull, @NotEmpty, @NotBlank, @Email 등의 애노테이션으로 클라이언트 요청으로 값을 검증하는 것은 필드 자체의 형식이나 값을 체크하는 용도로만 사용됩니다. 즉 필드와 필드를 비교하..
해당 프로젝트를 진행한 지 좀 오래되었지만 정리는 꼭 해야 된다고 생각하여 좀 많이 늦은 감이 있지만 이제라도 작성해봅니다. 왜 잘못된 설계를 했는가? 해당 프로젝트의 게시판의 종류는 중고나라, 도서 리뷰, 구인구직, 강의 등이 존재한다. 현재 Entity의 설계는 게시판 종류별로 Table을 가지는 형태이다. 왜 이렇게 설계 했는가? 그때 당시를 생각해보면.. 팀원별 각자의 도메인을 따로따로 분배받아 만들다 보니 각자의 도메인에 맞는 CRUD를 우선적으로 완성하다 보니 이렇게 설계가 된 것 같다. (JPA와 데이터베이스 공부를 열심히 안 한 것이 제일 크지만..) 이때 당시에 프로젝트를 끝나고 느낀 점은 완벽한 설계는 아니더라도 어느 정도 Table 설계를 진행하여 공통적으로 묶을 수 있는 테이블에 대..
이전 글과 이어지는 내용입니다. 안 읽어도 본문의 내용과는 상관없지만! 궁금하시면 읽어주세요! https://k3068.tistory.com/97 성장을 확인할 수 있는 척도는 무엇일까? 개발자로 성장하기 위해 1일 1 커밋 , 기술 블로그 활동을 하면서 해당 활동을 하면 분명 내가 남긴 기록을 통해 열심히 하고 있다는 것을 느낄 수 있지만 정말로 예전의 나보다 조금 더 좋은 개 k3068.tistory.com 오래된 토이 프로젝트를 리펙토링을 진행해보자. 어떻게 진행할까?! 솔직히 어느 부분부터 고쳐야 할지 막막했지만 저는 다음과 같이 기준 세우고 리펙토링을 진행했습니다. 도메인을 선택! 도메인 package 구조 파악하기! 도메인 Entity 파악! Controller -> Service -> Rep..
EntityManager는 쓰레드 간에 공유를 하지 않고 사용 후 바로 정리해야 한다고 한다. public void run(ApplicationArguments args) throws Exception { EntityManager em = entityManagerFactory.createEntityManager(); EntityTransaction transaction = em.getTransaction(); transaction.begin(); try { Member member = new Member(); member.setName("kjj"); em.persist(member); transaction.commit(); } catch (Exception e) { transaction.rollback(..
개발자로 성장하기 위해 1일 1 커밋 , 기술 블로그 활동을 하면서 해당 활동을 하면 분명 내가 남긴 기록을 통해 열심히 하고 있다는 것을 느낄 수 있지만 정말로 예전의 나보다 조금 더 좋은 개발자로 성장했는가? 단지 그냥 읽고 지나친 거에 불과하면서 나는 배웠어!라는 착각을 가지고 있지는 않을까? 이 두 가지의 생각은 항상 머릿속에 존재하는 것 같다. 해당 생각에 대해서 큰 비용이 들지 않고 쉽게 점검할 수 있는 방법은 제가 생각하기엔 본인이 진행한 작은 프로젝트라도 한 번쯤은 되돌아보는 것이 가장 큰 도움이 된다고 생각합니다! 따라서 이번 본문에서는 왜 그렇게 생각하는지 말해보고자 합니다. 성장하기 위해서는 토이 프로젝트를 (많이) 경험해보는 것이다!? 빠르게 성장하기 위해 대부분 조언으로 해주는 말..
이번글에서 소개하고자 하는 것은? 이번 글에서는 컨트롤러에서 @AuthenticationPrincipal 을 사용하여 Principal 객체를 바인딩 받아 사용하는 경우를 테스트 코드를 작성하기위한 글입니다. (테스트를 작성하는 방법은 여러가지 있음으로 해당 글이 무조건 옳은 방법의 테스트라고 주장하는 글이 아닙니다.) 서론 컨트롤러 예제는 다음과 같습니다. @GetMapping("/hi") public ResponseEntity hi(@AuthenticationPrincipal AuthUser user) { return ResponseEntity.ok("Hi !" +user.getEmail()); } 해당 컨트롤러를 테스트하기위해서는 AuthUser가 SercurityContextHolder 에 담겨 ..
JPA를 사용하게 되면 트랜잭션 격리 수준이 READ COMMITTED 정도가 된다. 격리 수준 READ UNCOMMITTED (거의 안 써요!) 커밋되지 않은 데이터를 읽을 수 있음 -> Dirty Read , Dirty Write 발생 가능 READ COMMITTED 커밋된 데이터만 읽기 -> Read Skew 발생 가능 REPEATABLE READ 트랜잭션 동안 같은 데이터를 읽게 함 -> Lost Update 발생 가능 SERIALIZABLE 모든 트랜잭션을 순서대로 실행 (실제로는 인덱스 잠금이나 조건 기반 잠금을 사용) 트랜잭션 격리 수준이 높아질수록 오버헤드가 커짐으로 잘 선택하여 사용해야 합니다. JPA를 사용하면서 READ COMMITTED 이상의 격리 수준이 필요할 때 비관적 락 , 낙..
