#1. 오늘의 학습 키워드 자바 스프링에서의 N+1 문제 에 대해서 JPA를 적용하는 과정에서, DB에 관련된 이모저모를 알아보는 과정에서 또 하나 재밌는 개념을 발견했다. 트랜잭션, MVC 패턴 등은 이미 백엔드 코드 구현 중에 체득되어있는 지식들이지만, 해당 문제에 대한 대비는 아직 백엔드 코드에서 이뤄지지 않은 것 같다. 혹은 눈치를 채지 못했거나. 또한 분명 대학교 수업 시간에 배웠던 기억이 있지만, 가물가물하기에 다시 한 번 상기시켜보도록 하자. #2. 공부한 내용 N+1 문제 연관 관계에서 발생하는 이슈 연관 관계가 설정된 Entity를 조회할 시, 조회된 데이터 개수 (N) 만큼 연관 관계가 있는 데이터를 추가로 조회하는 쿼리를 발생시키는 문제 쉽게 말하면 1번 쿼리로 조회하고자 하는데 N ..

#1. 오늘의 학습 키워드 자바 스프링에서의 Transaction 에 대해서 JPA, myBatis 동시 사용을 위한 multitransaction 을 구현하기 전 Transaction 자체에 대해서 알아보고 넘어가자. DB 수업 시간에 아주 중요한 파트를 차지했던 Transaction. 이렇게 수업시간에 배웠던 내용들을 실제 코드에서 구현하는 것은 재밌는 일이다. 트랜잭션의 구현은 복잡할 줄 알았는데, Spring에서는 굉장히 쉬운 방법을 제공하고 있었다. #2. 공부한 내용 Transaction 트랜잭션 더 이상 쪼갤 수 없는 업무 처리의 최소 단위. 예) A → B 에게 송금할 때: A는 돈을 지불하고 B는 돈을 받는 것. 이 작업들은 하나의 트랜잭션으로 쪼갤 수 없다. 트랜잭션의 특징: ACID ..

#1. 오늘의 학습 키워드 자바 스프링에서 Hikari 에 대해서 현재 회사에서 기존에 사용하던 MyBatis에 추가로 JPA를 도입하려한다. 두 기술을 동시에 사용하려다보니 고려사항이 많아진다. 그 중 현재 본인이 대응해야하는 것은 멀티 트랜잭션 관련 문제다. 기존 MyBatis로 설정된 transaction Manager 와 JPA로 설정된 transaction Manager 가 다르기에 묶어줘야하거나, 단일 트랜잭션을 묶어서 사용해야한다. 해당 문제를 해결하기 전에 CP와 히카리(Hikari)에 대해 짚고 가기 위해 글을 쓴다. (해결과정은 추후 블로그 글을 올리겠다) #2. 공부한 내용 JDBC Java Database Connectivity 자바에서 DB에 쿼리를 던지거나, 수정 할 수 있도록 ..

#1. 오늘의 학습 키워드 자바 스프링에서 MVC 의 개념 노드에서 자바 스프링부트로 리팩토링하는 과정에서, 개인적으로 언어 자체의 친숙도 문제 이외에는 크게 어려운 작업이 아니었던 이유는 코드 패턴이 흡사하였기 때문이다. Node Router (controller) → Service → DAO 패턴 Spring Controller → Service → Repository 패턴 여지껏 위 패턴으로 백엔드 개발을 진행해왔다 보니, 스프링을 사용하여 개발을 할 때는 MyBatis 를 사용하였기에 SQL 쿼리를 직접 구현하는 부분 제외하고는 처음엔 크게 익숙치 않은 구석은 없었다. 그럼 이쯤에서 질문을 할 수 있겠다. 이러한 패턴은 뭐라고 부르는 것일까? 이러한 패턴은 직접 사용해보니 직관적이고 구현하기 편리..

#1. 오늘의 학습 키워드 자바 스프링에서 AOP 의 개념 회사 내 백엔드 로직의 캐시를 도입하는 도중, 캐시 처리된 로직을 테스트 하던 중 redis 서버과의 연결이 안 된 상황에서 테스트가 된 적이 있었다. 그때 디비와의 연결은 문제가 없는데도, 캐시가 처리된 로직은 redis 서버만 다운되면 api 호출 시 에러가 났다. 개인적으로는 당연히 캐시 서버가 다운되면 디비로부터 정보를 가져와야 되는 게 아닌가라는 생각을 했다. 안타깝게도 그런 기능은 직접 구현해야됐던 상황이었다. 해당 기능을 구현하는 상황에서 모든 캐시 어노테이션 쪽에 디비와의 연결을 보장하는 로직을 공통적으로 적용되는 코드로 추출하고 싶었는데, 이러한 개념을 AOP 라고 한다는 것을 깨달았다. 사실 이미 공통적으로 사용되는 날짜, St..

#1. 오늘의 학습 키워드 자바 스프링에서 POJO 클래스란 무엇일까 @Controller, @Service, @Repository, @Configuration 등 Bean 으로 등록 할 객체들의 대응하는 클래스들을 뭐라고 통칭할 지 궁금해졌다. controller → service → repository 의 기본적인 백엔드 개발 구조는 노드로 백엔드 개발 시작했을 때부터 익숙하였기에, 각 컴포넌트의 의미에 대해서는 자연스럽게 받아드렸다. 그러나 노드에서는 각 구조에 대해서 따로 노드가 관리를 해주는 게 아닌, 코드의 로직 자체가 자신이 어떤 역할을 담당하는 지 정했었다. 스프링에서는 클래스 선언 부 상단에 해당 클래스가 어떤 컴포넌트에 속하는 지 어노테이션을 명시를 해주었는데, 이 행위가 어떤 의미를 ..