정합성 보장 WAS 여러대에서 정합성 보장 쓰기 DB가 여러대에서 정합성 보장 실행 속도 (실험) 작업 순서 처리 보장 동시성 고려 X X X X 1m 1s X synchronized X X X 4m 56s O 비관적 락 O O X 4m 32s O 낙관적 락 O O (#1) X 1m 5s X Redisson 락 O O O 4m 44s O #1 : 해줄 것으로 생각됨 동시성 고려를 하지 않은 경우 아래 이미지처럼 기대 예약 개수인 250개 보다 많은 366건이 예약됨을 알 수 있다 동시성 처리를 위해 synchronized를 사용한 경우 @Transactional synchronized public long bookPerformance(...) { //공연 예매 로직 } synchronized 위치가 저기..

전에 작성한 글이 길어져서, 포스팅을 분리했다 동작 흐름 ArgumentResolver는 아래와 같은 순서로 호출된다 Handler의 각 Parameter 리스트 순회한다 Argument Resolver 리스트를 순회하면서 1번의 Parameter의 타입에 일치하는 것을 찾는다 즉 O(N^2)이다 InvocableHandlerMethod 를 보도록 하자 (HandlerMethod의 자손) 먼저 파리미터들 목록을 가져온다 그 후 arguemntResolver들의 목록을 순회한다 언제 ModelAttributeMethodProcessor를 거치는가 결론: 커스텀 클래스인 모든 경우. (단, 커스텀 클래스에 대응하는 ArgumentResolver가 없는 경우) 먼저, 들어가기전에 간단히 알고 넘어갈 게 있다 ..

결론: ArguemntResolver를 WebMvcConfigurer에 등록하지 않음 이글을 쓰는 이유는 MVC에 대한 이해도가 다소 높아진 게기가 되어서 작성했다 알게 된 바에 의하면 웹 요청이 있으면 Dispatcher Servlet -> Interceptor 목록 순회 -> Handler Adapter -> ArgumentResolver -> Handler (Controller 위와 같은 순서로 진행이 된다 조금 더 상세히 얘기하면 Dispatcher Servlet 를 거친 후 해당 요청 URL에 대한 Interceptor 목록을 순회한 후 Handler Adapter 목록을 조회 (대부분의 경우 RequetMappingHandlerAdapter)후 이동할 Handler에 대한 Argument목록 ..

JPA 로그를 보다보면 select ~ from 테이블 where col1 = ? and col2 = ? 로 포맷팅 되지 않은 형태로 sql 로그가 찍히는 걸 볼 수 있다 1. 개행 없음 2. 바인딩 되는 파라미터 정보 부재 spring data jpa 기능으로만 위 1, 2 문제는 해결이 가능하다, 그러나 select ~ from 테이블 where col1 = ? and col2 = ? ~ binding parameter ['1'] ~ binding parameter ['philz'] 로 파라미터와 sql로그가 따로 찍혀서 불편하게 해석해야 한다 따라서 p6spy를 이용하면 저 물음표 자리에 파라미터 정보를 넣어서 편하게 볼 수 있다 select ... from 테이블 where col1 = '1' a..

때로, 기존 프로젝트를 작업하다가 원본 프로젝트를 그대로 둔 채 이름을 바꾸고 싶을 때가 있다 현재 내가 그런 상황에 있다, ticketing-service보다 performance-ticketing-service로 바꾸고 싶은 것,, 이에 따라 Git도 변경해주면 된다 (이건 GPT가 잘 설명해줬다.) 기존에 내가 알고 있던 것과 일치하고, 명령어도 다시 한 번 점검 후 사용했다 Gradle 프로젝트 변경하기 다만 GPT-4가 Gradle 변경은 아쉽게 알려주었다 우선 나의 경우 매번 잊기 때문에 (왜냐하면 이걸 할 일이 많지 않음) 확인하는 수단이 따로 있다 아래 사이트로 이동하자 (이 사이트를 모르면서 Spring 개발하는 분은 없겠지..?) https://start.spring.io/ 자기 상황에..

사진: Unsplash의Praveen Thirumurugan 종종 이전 디렉터리의 커밋 내역을 포함해서 복사를 하고 싶은 상황이 있다 그런 경우에 유용하다 원격 리포지토리를 추가후에, 옮기고자 하는 자식 디렉터리에 끌고 오는 방식이다 # child repo 추가 git remote add {child} {child repo 주소} git subtree add --prefix={디렉터리명} {리포 이름} {리포의 브랜치} git subtree add --prefix=child-dir child main 참고로 아래처럼 -P로 축약해서 사용 가능 참고로 디렉터리를 만들 필요가 없다. (알아서 만들어준다)만들게 될 경우, "prefix 'child-dir' already exists." 라는 에러가 뜬다. 만..

기록 이유 앞으로 주간/월간으로 헬스 일지를 기록하려고 한다 그래야 내 운동 능력의 변화를 관찰할 수 있을 것 같다 ! 히스토리 주간 -> 월간으로 변경 이유: '주'를 기준으로 하면 각 부위별 증/감을 체감하기 어려울 것이라고 판단 운동 루틴 [금주의 알고리즘 설정] 무게 12회를 할때 실패하는 무게 지점까지 하고, 거기서 2~3개씩 무게를 낮추며 최소 6개까지 하는 무게까지 맥스로 삼는다 (그 이상은 부상의 우려가..) 그리고 그 6개을 7개 8개로 조금씩 늘려나가고 다음 6개 무게로 나아간다 -> 변경 무게를 굳이 내려가지 않는다 이렇게 한 이유는 다른 운동들이 추가됨에 따라 운동 시간이 너무 늘어나게 됨 (1시간 반 초과) 다른 종목을 더 넣고 쉬는 시간을 더 길게 가져감 힘 힘이 드는 곳은 빠르..

예를 들어 회원의 정보를 반환할 때, 해당 회원에 대한 상품 목록이 필요하다면 회원 서비스는 주문 서비스에 요청을 해야한다 Http Client 정보를 가져오는 것(GET)은 Http Client를 이용하며 크게 3가지 있다 - RestTemplate - FeignClient - WebClient 이 세가지는 다른 곳에도 많은 설명이 있기에 간단히만 짚고 넘어가자 RestTemplate 전통적인 Http Client, Deprecated 한다는 얘기가 있으나, 취소된 것으로 보인다 (토비님 영상[ https://youtu.be/S4W3cJOuLrU ]) FeignClient 넷플릭스에서 만든것이고 인터페이스로 보다 더 쉽게 사용할 수 있다 WebClient 앞선 두개와 달리 비동기 요청이 가능하다. We..

보통 yaml 파일을 리펙터링하면 서버를 재기동하면서 제대로 설정됐는지를 확인한다 내 노트북 같은 경우 보통 재기동하면 40초 ~ 2분 정도의 시간이 걸린다... 참으로 답답하지 않을 수 없다 Spring Cloud Config 을 이용하면 변경한 yaml 파일을 동적으로 반영해서, 빠르게 리펙터링을 해나갈 수 있다 우선 아래 정보를 참고해서 Spring Cloud Config을 설정한다 (설명이 친절하지 않아서 미안...) - Section 7: Cloud Configuration (tistory.com) - Section 8, 9: Cloud Bus, 암호화 (tistory.com) 아래와 같은 상황이 있다고 가정해보자 (내 상황이었음) 정~말 긴 yml 파일이 있는데... route 설정 정보로 인..

설정 정보 반영하는 방법 세 가지 1. 서버 재기동 2. Actuator Refresh 3. Spring Cloud Bus 1 -> 2로 가면서 동적으로 설정 정보 변경이 가능하나 각 서비스에 대해 해줘야 한다 3은 일괄 적용 가능 Cloud Bus 개념 클라우드 버스 자체는 애플리케이션들 사이의 상태 변화를 감지하고 이벤트를 전파해서 전체 시스템 간의 상호작용과 동기화를 하는 것을 뜻한다 수단은 메시지 브로커(RabbitMQ, Apache Kafka)(AMQP)를 사용해서 이벤트를 송수신한다 강의에서는 설정 정보를 애플리케이션들에 일괄 반영(broadcast)하기 위해 사용했다 Erlang, Rabbit MQ 설치 역시나... 한번에 되지 않았다 Rabbit 이전 버전 installer 를 못찾아서 결..

멀티모듈을 하면서 갑자기 잘만되던 eureka에 api gateway 등록이 안되었다 문제가 무엇인지 보니 아래처럼 dependency가 없어졌던걸 확인했다 위처럼 applicatoin.yml를 확인하면, 속성을 reslove하지 못한 것 위주로 import하면 해결할 수 있다 (컴파일 문제의 경우 빌드 자체가 실패하기 때문에 쉽게 알아낼 수 있다) 나의 경우 eureka client 의존성이 없는게 문제였다 아래처럼 dependencies 추가하면 간단히 해결된다 dependencies { // Service Registry Client implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client' }

그레이들을 건드리면서 한숨을 참 많이 한것 같다 ( 이 코끼리자식아 ) 머만 하면 컴파일 에러가 뜨지 않나... 자바와는 다르게 빠르게 시행착오를 통해 배우는게 쉽지 않다 사실 지금도 정확히 안다기보다는 대략 이런 느낌으로 하면 버그를 없앨 수 있지않을까... 하면서 진행했던게 도움이 되었다 공식문서, 유튜브 등을 참고 해봤지만 크게 도움되지는 않았던 것 같다 서론이 길었다, 멀티 모듈하면서 공통 의존성들이 많이 생긴다. 이걸 관리하는 방법은 크게 두 가지이다 이펙티브 자바식으로 얘기하면 상속과 조합이다 (Gradle에서 공식적으로 사용하는 용어가 아닙니다!) 상속 부모 디렉터리에 공통 의존성을 정의한다 그러면 자식은 그 의존성을 받기만 하면 되며 별다른 설정은 하지 않아도 된다 예를 들면, 내가 실제로..