back to the 0

MVC 진행 과정 클라이언트가 url을 요청하면, 웹 브라우저에서 스프링으로 request가 보내진다. Dispatcher Servlet이 request를 받으면, Handler Mapping을 통해 해당 url을 담당하는 Controller를 탐색 후 찾아낸다. 찾아낸 Controller로 request를 보내주고, 보내주기 위해 필요한 Model을 구성한다. Model에서는 페이지 처리에 필요한 정보들을 Database에 접근하여 쿼리문을 통해 가져온다. 데이터를 통해 얻은 Model 정보를 Controller에게 response 해주면, Controller는 이를 받아 Model을 완성시켜 Dispatcher Servlet에게 전달해준다. Dispatcher Servlet은 View Resolver..

-Dispatcher-Servlet 서블릿 컨테이너에서 HTTP 프로토콜을 통해 들어오는 모든 요청을 제일 앞에서 처리해주는 프론트 컨트롤러 따라서 서버가 받기 전에, 공통처리 작업을 디스패처 서블릿이 처리해주고 적절한 세부 컨트롤러로 작업을 위임 디스패처 서블릿이 처리하는 url 패턴을 지정해줘야 하는데, 일반적으로는 .mvc와 같은 패턴으로 처리하라고 미리 지정해줍니다. 디스패처 서블릿으로 인해 web.xml이 가진 역할이 상당히 축소되었습니다. 기존에는 모든 서블릿을 url 매핑 활용을 위해 모두 web.xml에 등록해 주었지만, 디스패처 서블릿은 그 전에 모든 요청을 핸들링해주면서 작업을 편리하게 할 수 있도록 도와줍니다. 또한 이 서블릿을 통해 MVC를 사용할 수 있기 때문에 웹 개발 시 큰 장..

페이징 -페이지 단위의 논리-물리 주소 관리 기법. 논리 주소 공간이 하나의 연속적인 물리 메모리 공간에 들어가야하는 제약을 해결하기 위한 기법 -논리 주소 공간과 물리 주소 공간을 분리해야함(주소의 동적 재배치 허용), 변환을 위한 MMU 필요 특징 : 외부 단편화를 없앨 수 있음. 페이지가 클수록 내부 단편화도 커짐 세그먼테이션 -사용자/프로그래머 관점의 메모리 관리 기법 -페이징 기법은 같은 크기의 페이지를 갖는 것 과는 다르게 논리적 단위(세그먼트)로 나누므로 미리 분할하는 것이 아니고 메모리 사용할 시점에 할당됨

교착상태(DeadLock)란? -프로세스가 자원을 얻지 못해 다음 처리를 하지 못하는 상태 -시스템적으로 한정된 자원을 여러 곳에서 사용하려고 할 때 발생하는 문제 교착상태의 4가지 조건 상호배제 : 프로세스들이 필요로 하는 자원에 대해 배타적 통제권을 요구함 점유대기 : 프로세스가 할당된 자원을 가진 상태에서 다른 자원 기다림 비선점 : 프로세스가 어떤 자원의 사용을 끝날 때까지 그 자원을 뺏을 수 없음 순환대기 : 각 프로세스는 순환적으로 다음 프로세스가 요구하는 자원을 갖고 있음 -이 4가지 조건 중 하나라도 만족하지 않으면 교착상태는 발생하지 않음 (순환대기는 점유대기와 비선점을 모두 만족해야만 성립합. 따라서 4가지가 서로 독립적이진 않음) 교착상태 해결 방법 4가지 -예방 -회피 -무시 -발견

멀티 프로세스로 처리 가능한 걸 굳이 멀티 스레드로 하는 이유는? -프로세스를 생성하여 자원을 할당하는 시스템 콜이 감소함으로써 자원의 효율적 관리가 가능함 -프로세스 간의 통신(IPC)보다 스레드 간의 통신 비용이 적어 작업들 간 부담이 감소함 -멀티 스레드를 사용할 때는 공유 자원으로 인한 문제 해결을 위해 '동기화'에 신경써야 함

Problem: My Diary가 mypage 내에서 나타나지 않는 현상 Why?: Browser 라우팅 경로가 잘못되있었다... 분명 컨설팅 받을때도 브라우저 라우팅 잘해야한다고 받았는데 이거 하나때문에 너무 긴 시간을 투자...

Problem: 프론트와 백 통신이 안되는 현상.. Why?: CORS 정책에 위배되어 발생 Solution: Proxy 설정에 백엔드 IP를 할당 Problem: Diary db 속성이 자꾸 변경되어 코드 실행 불가 Why?: 서로 다른 브랜치에서 작업하다보니 diary entity 코드가 달랐고, 이를 JPA가 db속성 변경을 해버림 -> 깃허브 최신화

Problem: 일반 감정채팅방과 스파링채팅방의 채팅방 중복현상 Why?: 일반 감정채팅방 입장시 최소 사진 입력값에 따른 roomIndex 값으로 입장, 이때 roomIndex 값은 1, 2, 3 스파링채팅의 roomIndex의 최초 값도 1로 설정되어있어 입장시 중복 현상 발생 Solution: 스파링채팅방의 roomIndex의 최초값을 10부터 시작하도록 코드 변경

Problem: 사용자 목록은 이제 제대로 출력이 되지만 다음 사용자가 들어와도 사용자 목록이 업데이트 되지않음 Why?: 비동기방식으로 서버와의 연결을 유지하여 서버로부터 최신데이터를 받아와야 하지만 클라이언트측에서 최초 한번만 호출후 연결종료하여 유저목록이 업데이트되지 않음 Solution: 클라이언트측 호출방식 변경 후 문제해결

Problem: 클라이언트측에서 사용자값은 서버쪽으로 들어오지만 서버에서 다시 Map으로 저장하여 클라이언트로 반환할때 클라이어트 측에서 출력이되지 않음 Why?: 서버쪽에서 Map 형식으로 key값을 roomId로 설정하고 value값 에 다시 유저 목록을 저장 이때 저장은 되지만 클라이언트에서 사용자 목록을 호출할때 roomId값이 제대로 삽입되지 않아 사용자 Set값을 제대로 호출하지 못함 Solution: roomId값이 제대로 호출되도록 roomId호출 로직 변경