
커넥션 풀 커넥션 풀은 데이터베이스 연결을 관리하는 데 사용되는 메커니즘이다. 데이터베이스 연결을 생성하고 닫는 과정은 비용이 많이 들기 때문에 애플리케이션에서 데이터베이스와의 연결을 효율적으로 관리하기 위해 연결 풀을 사용한다. 커넥션 풀 등장배경 데이터베이스 커넥션을 획득할 때는 다음과 같은 복잡한 과정을 거친다. 애플리케이션 로직은 DB 드라이버를 통해 커넥션을 조회한다. DB 드라이버는 DB와 TCP/IP 커넥션을 연결한다. 물론 이 과정에서 3 way handshake 같은 TCP/IP 연결을 위한 네트워크 동작이 발생한다. DB 드라이버는 TCP/IP 커넥션이 연결되면 ID, PW와 기타 부가정보를 DB에 전달한다. DB는 ID, PW를 통해 내부 인증을 완료하고, 내부에 DB 세션을 생성한다..

JDBC JDBC(Java Database Connectivity)는 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API다. JDBC는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다. JDBC가 나오게 된 배경 클라이언트가 애플리케이션 서버를 통해 데이터를 저장하거나 조회하면, 애플리케이션 서버는 다음 과정을 통해서 데이터베이스를 사용한다. 커넥션 연결: 주로 TCP/IP를 사용해서 커넥션을 연결한다. SQL 전달: 애플리케이션 서버는 DB가 이해할 수 있는 SQL을 연결된 커넥션을 통해 DB에 전달한다. 결과 응답: DB는 전달된 SQL을 수행하고 그 결과를 응답한다. 애플리케이션 서버는 응답 결과를 활용한다. 하지마 각각의 데이터베이스마다 커넥션을 연결하는 방법, SQL을 전달..

스프링 내부구조 Web Server Client는 HTTP 프로토콜을 이용하여 요청을 보내게 된다. 웹 서버는 이를 해석해 요청에 맞는 데이터를 보내주어야 한다. 그에 맞는 데이터 형식으로 보내주는 것이 Web Server가 할 일이다. 웹 서버는 단순히 요청에 대한 데이터를 수정없이(static, 정적) 클라이언트에게 보내주기만 하면 된다. 초창기 인터넷에서는 정적 데이터에 대한 수요가 높았기 때문에 기능적으로 WAS를 따로 나누지 않고 웹 서버라는 개념을 통칭해서 사용했다. WAS(Web Application Server) WAS는 J2EE 스펙을 구현하여, 서블릿이나 JSP로 작성된 애플리케이션을 실행하는 소프트웨어이다. 참고: J2EE(Java 2 Platform, Enterprise Editio..

HTTP Request 파싱하기 이전 게시글에서 HTTP Request가 출력되는 것을 확인했다! 그러면 이제 HTTP Request를 파싱해보자. 이렇게 HTTP Request를 파싱하는데에는 이유가 있다. 우리가 사용하는 스프링 프레임워크는 모두가 알다시피 서블릿 스펙을 지킨 서블릿 컨테이너를 구현하고 있다. 다시 말하자면 서블릿 컨테이너의 주요 목표는 서블릿을 동작시키는데 있다고 볼 수 있다. 따라서 서블릿이 어떤 방식으로 동작하는지를 이해하면 서블릿 컨테이너가 제공해야 하는 기능을 역으로 유추할 수 있다. 그리고 이런 서블릿의 목적은 HTTP 프로토콜을 사용해 웹 서비스를 제공하는 것이다. 그럼 이 서블릿 스펙을 구현한 서블릿 컨테이너는 네트워크 통신, 생명주기 관리, 스레드 기반의 병렬처리를 대..

Socket을 이용한 HTTP Server HTTP 통신은 당연히 Socket을 이용하는건데 어떻게 제목이 Socket을 이용한 HTTP Server이다. 이전 게시글 소켓을 활용한 Echo Server 만들기 소켓(Socket) 소켓은 네트워크에서 실행되는 두 프로그램 간의 양방향 통신 링크의 양 끝점을 말한다. 즉, 프로세스가 데이터를 보내거나 받기 위해서는 반드시 소켓을 열어서 소켓에 데이터를 써 oneny.tistory.com 소켓에 대한 개념과 소켓을 통해 에코 콘솔 서버 만든 게시글이다. HTTP Server 개요 1. Configuration 파일 읽기 프로그램의 설정 정보를 저장하는 파일을 읽어와서 프로그램이 동작할 환경설정을 구성한다. 이 설정은 포트번호, 파일 경로, 데이터베이스 연결 ..

Spring WebFlux에 대해 깊이있게 공부하기 보다는 Spring MVC와 Spring WebFlux를 통해 Blocking 방식과 Non-blocking 방식에서 스레드가 어떻게 동작하는지에 대해서 가볍게 알아보려고 합니다. 관련 블로그 blocking I/O vs non-blocking I/O (feat. socket I/O) I/O I/O는 input/output의 약자로, 데이터의 입출력을 의미한다. 이러한 I/O의 종류에는 일반적으로 우리가 알고 있는 file I/O, 프로세스 간의 통신을 할 때 사용되는 pipe I/O이 있다. 그리고 일반적인 디 oneny.tistory.com 위에서 Blocking I/O와 Non-blocking I/O에 대해서 공부했던 글이다. Spring MVC와..

데드락(Deadlock) 운영체제 또는 소프트웨어의 잘못된 자원 관리로 인하여 둘 이상의 프로세스 또는 스레드들이 아무것도 진행하지 않는 상태로 서로 영원히 대기하는 상황을 말한다. 주로 한정된 자원을 여러 프로세스 및 스레드에서 동시에 사용하는 환경에서 서로 상대방이 사용 중인 자원을 쓰기 위해 대기하는 상황, 그러니깐 A가 B를 기다리고, B가 A를 기다릴 때 발생한다. 발생조건 상호 배제(Mutual Exclusion): 한 번에 한 스레드만 단독으로 리소스에 액세스할 수 있다. 즉, 리소스 자체를 동시에 쓸 수 없으며 한 번에 하나의 스레드만이 해당 리소스를 사용할 수 있다. 점유 상태로 대기(Hold and wait): 최소 하나의 스레드가 리소스를 점유하면서 다른 리소스에 대기를 해야 한다. ..

소켓(Socket) 소켓은 네트워크에서 실행되는 두 프로그램 간의 양방향 통신 링크의 양 끝점을 말한다. 즉, 프로세스가 데이터를 보내거나 받기 위해서는 반드시 소켓을 열어서 소켓에 데이터를 써보내거나 소켓으로부터 데이터를 읽어들여야 한다. 다시 말해, 소켓은 떨어져 있는 두 호스트를 연결해주는 도구로써 인터페이스의 역할을 하는데 데이터를 주고 받을 수 있는 구조체로 소켓을 통해 데이터 통로가 만들어진다. 이러한 소켓은 역할에 따라 서버 소켓과 클라이언트 소켓으로 구분되는데 이에 대해서는 뒤에서 자세히 살펴보자. 소켓의 역할 클라이언트-서버 응용 프로그램에서 서버는 사용자가 원하는 정보를 전송하여 보여주는 서비스를 일부 제공한다. 이러한 클라이언트와 서버 간에 발생하는 통신은 신뢰할 수 있어야 한다. 즉..

타입 안전 이종 컨테이너 타입 안전 이종 컨테이너는 한 타입의 객체만 담을 수 있는 컨테이너가 아닌 여러 다른 타입(이종)을 담을 수 있는 타입 안전한 컨테이너를 말한다. 이렇게 하면 제네릭 타입 시스템이 값의 타입이 키와 같음을 보장해주는데, 이러한 설계 방식을 타입 안전 이종 컨테이너 패턴이라고 한다. 일반적으로 사용하는 제네릭의 한계 public class Favorites { List value; public static void main(String[] args) { Favorites names = new Favorites(); names.value.add("oneny"); names.value.add("twony"); Favorites numbers = new Favorites(); } } 제..
- Total
- Today
- Yesterday
- 구름톤 챌린지
- mysql
- nginx configuration
- Synchronized
- spring webflux
- NeXTSTEP
- socket
- 비관적 락
- Java
- 트랜잭션
- pessimistic lock
- spring session
- Kafka
- 넥스트스탭
- 구름톤챌린지
- annotation
- 카프카
- 람다
- sql
- mdcfilter
- TDD
- ip cidr
- webflux spring security
- amazon subnet
- transaction
- nginx
- redis session
- 분산 락
- postgresql
- jvm 메모리 구조
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |