두 엔티티 간에 영속성 전이가 제대로 이루어지려면?현재 진행하고 있는 개인 프로젝트에서 다음과 같이 엔티티들의 연관관계가 설정되어 있다. Member -- (OneToMany) -- History -- (OneToMany) -- Question 그리고 저장 및 테스트를 용이하게 하기 위해 Member에dockerel.tistory.com N+1 문제 해결 후기는 위 글과 이어집니다. 엔티티 영속성 전이 문제를 어찌어찌 해결한 후 한시름 놨다고 생각할 때쯤 쿼리 로그를 보니 뭔가 이상했다.  무수한 SELECT 요청이 날아가고 있었고, 딱 보자마자 N+1 문제라는 느낌이 확 왔다. 그런데 사실 그도 그럴 것이 기존에 멤버가 질문한 개수를 구하는 로직은 이렇게 작성되어 있었다.  멤버의 history를 구하..

현재 진행하고 있는 개인 프로젝트에서 다음과 같이 엔티티들의 연관관계가 설정되어 있다. Member -- (OneToMany) -- History -- (OneToMany) -- Question 그리고 저장 및 테스트를 용이하게 하기 위해 Member에서 Question까지 CascadeType.ALL을 통해  영속성 전이를 설정해 놓았다. 그리고 Member, History 그리고 Question을 저장하고 Member가 올린 총 Question의 수를 구해오는 테스트를 작성하였다. @DisplayName("유저가 존재하면 유저의 이메일, 닉네임, 가입날짜, 해당 유저의 질문 개수를 반환한다.")@Testvoid getMyInfoWithExistMemberId() { // given Stri..

CORS(Cross Origin Resource Sharing)은 출처가 다른 리소스를 요청할 때 접근 권한을 부여하는 메커니즘으로 리소스를 주고받는 두 곳의 출처가 다르면 출처가 교차(Cross Origin)한다고 말한다. 이때 출처는 URL, 프로토콜 그리고 포트까지 포함되며 서버에서 허용하지 않은 클라이언트가 요청을 할 시에 CORS 에러가 발생할 수 있다. CORS가 필요한 이유? 이전에는 CSRF(Cross-Site Request Forgery) 문제가 있었다.   공격자에 의해 사용자가 가짜 요청을 날리게 되는 공격으로, 위 그림에서는 공격자가 만든 가짜 사이트로 인해 피해자가 자신의 정보를 이용하여 돈을 이체하게 된다.  이를 막기 위해 SOP(Same-Origin Policy)를 구현하였다..

저번 포스팅에서 MVCC 사용 시 팬텀 리드가 발생할 수 있는데 이를 갭 락과 넥스트키 락으로 해결할 수 있다고 했다. 이에 대해 좀 더 자세히 알아보자.  데이터베이스 시스템에서 동시성을 제어하는 방법은?데이터베이스 시스템에서 동시성을 제어하는 방법으로는 MVCC(Multi-Version Concurrency Control)과 Lock-Based Concurrency Control이 있다. MVCC(Multi-Version Concurrency Control)  MVCC는 데이터의 여러 버전을 유지하여dockerel.tistory.com 팬텀 리드란?  팬텀 리드(Phantom Read)란 트랜잭션이 동일한 조건의 쿼리를 반복해서 실행할 때 처음 실행했을 때의 결과에서 존재하지 않았던 새로운 행이 나타..

데이터베이스 시스템에서 동시성을 제어하는 방법으로는 MVCC(Multi-Version Concurrency Control)과 Lock-Based Concurrency Control이 있다. MVCC(Multi-Version Concurrency Control)  MVCC는 데이터의 여러 버전을 유지하여 트랜잭션이 동시에 데이터를 쓰고 읽을 수 있다. 즉, 각 트랜잭션은 각자만의 스냅샷을 기반으로 데이터를 읽는다. 하지만 이러한 특징 때문에 만약 T1 트랜잭션에서 쓰기 작업을 하고 커밋하지 않은 상태에서 T2에서 해당 변경 사항을 보지 못한다.  MVCC는 읽기 작업 시 락을 사용하지 않아 높은 동시성을 제공한다. 즉 읽기 작업은 락에 의해 지연되지 않아 읽기 위주의 작업이 많은 애플리케이션에서 좋은 성능..

멱등성은...그렇다고 한다.  즉 여러 번 같은 요청을 넣어도 서버의 상태가 동일할 경우 이를 멱등하다고 한다. 그리고 대표적으로 멱등한 메서드는 GET, HEAD, PUT, DELETE, TRACE, OPTIONS 가 존재한다.  이러한 멱등성은 HTTP 커넥션이 끊어졌을 때 다시 해당 요청을 해도 되는지에 대한 판단 근거가 된다. 만약 결제 내역 조회 등과 같은 GET 요청의 경우 여러 번 요청을 넣어도 문제가 되지 않을 것이다. 즉, 멱등하다면 요청을 재시도할 때 같은 서버의 상태를 보장하기 때문에 문제가 없다. 하지만 결제 요청의 경우 다시 해당 요청을 넣어버리면 중복 결제 문제가 생길 수 있을 것이다. 즉, 멱등하지 않다면 재시도 요청 시 중복 요청이 보내져 문제가 발생할 수 있을 것이다. 예를..

사용자가 크롬에 들어가서 www.naver.com을 입력하면...? 의 과정을 TCP/IP 5 계층을 기준으로 설명해 보겠습니다...위와 같이 네트워크에서 데이터가 처리되는 5계층이 존재한다.Application 계층크롬 브라우저는 HTTP 프로토콜로 네이버의 웹 서버와 통신하려 할 것이다. 이때 브라우저가 요청한 도메인 이름(www.naver.com)에 대한 IP 주소를 알아내기 위해 DNS(Domain Name Service) 서버에 요청을 보낸다. IP 주소를 얻고 나서 이제 브라우저는 네이버 서버와 통신을 시작한다.Transport 계층브라우저가 네이버 서버와 통신을 시작하기 위해 TCP 3-Way Handshake 를 한다. [매일메일] TCP 3-way handshake란?TCP 3-way ..

우선 결론부터 말하자면 아닐 확률이 크다.스레드가 많으면?스레드가 많으면 운영체제는 컨텍스트 스위칭을 자주 수행해야 하고 CPU의 자원이 이러한 스레드 관리에 소모된다. 이로 인해 다른 작업의 수행 효율이 떨어질 수 있으며, 많은 스레드가 동시에 실행될 경우 메모리, 캐시, 락 등의 자원을 경쟁하게 되어 성능 저하나 데드 락이 발생할 가능성이 높아진다. 또한 스레드가 많아지면 동기화와 상태 관리가 복잡해져 버그 발생 가능성도 커진다. 서블릿이 뭐에요?스프링 MVC에 대해 공부하던 중 서블릿에 대한 나름대로의 정리가 필요할 것 같았다. 그래서 먼저 위키에 서블릿이 뭔지 찾아봤다.뭐 그렇다는데, 영한님의 강의에서는 이렇게 서블릿을 설명해dockerel.tistory.com스프링의 경우 요청이 들어오면 스레드..