3단계: 멀티 스레딩으로 클라이언트 요청 동시에 처리하기
모든 프로그램은 동시 요청을 처리해야 한다
멀티 프로세싱 기능을 갖고 있어야 함
데이터 관리 프로그램을 퉁치자
Server
클라이언트가 접속을 하게 되면 스레드랑 통신을 한다
main이 호출되어서 끝날 때까지 실이 끊기지 않고 간다
처음에 서버를 실행하면 main thread가 실행을 쭉~ 진행한다.
스레드가 분기되면서 서로 간섭을 하지 않는다 (멀티 태스킹)
한 클라이언트가 접속을 끊을 때까지 기다릴 필요가 없이
단독적으로 서버랑 대화하는 듯이 동시 실행되는 것처럼 보인다.
무엇을 스레드로 실행합니까?
다른 클라이언트와 엮이지 않아야 되는 작업
RequestHandler 클래스 만들기
소켓을 가지고 입출력 스트림을 준비한 다음에
요청에 대해서 처리하는 거
close()를 자동으로 호출되게 하기 위해서
선언되어 있지 않으면 close()가 자동으로 호출되지 않는다
스레드를 가동시킬 때는 run()이 아니라 start()
임시 변수 만들지 말고 바로 안에 집어 넣기
클라이언트가 안 들어오면 계속 기다리고 있음 (블로킹)
RequestHandler 클래스 → ServerApp 클래스에 중첩 클래스로 두기
내부적으로 쓰니까 private로
로컬 클래스로 두는 게 개념적으로 맞지만
너무 코드가 길어서...
바깥 클래스의 인스턴스의 멤버를 쓰지 않으면 static 중첩 클래스로
ScoreTable scoreHandler = new ScoreTable();
인스턴스 만들어서 쓰는 거 아니니까 지우기
스태틱이어서 클래스명으로 호출함
멀티 태스킹 - 동시에 여러 개의 작업 수행
여러 개의 작업: 프로세스, 스레드
프로세스와 스레드의 관계
스레드
프로세스(실행중인 프로그램)
유튜브
웹브라우저
게임
운영체제가
이 명령어 조금
이 명령어 조금
이 명령어 조금
그래서 우리가 유튜브랑 브라우저랑 게임 동시에 가능
웹 브라우저라는 프로세스 안에서도 작업 여러 개를 동시에 실행
하나의 프로세스 안에 작은 작업들이 동시에 실행되는 거
작은 작업을 동시에 실행하는 거
• 메인 로고 다운로드 및 출력
• 음악 실행
• 롤링이미지 출력
• 메뉴 갱신
멀티 스레딩 : 동시에 여러 개를 실행하는 거
프로세스에 종속되어 있고
CPU가 얘 조금 얘 조금 왔다 갔다 하면서 실행
프로세스 안에 작은 작업들을 병행적으로 실행한다
운영체제는 스레드든 운영체제든 구분하지 않고 같은 걸로 판단하고 공동으로 분배한다. 골고루 분배한다.
프로세스에 할당된 시간을 나눠서 쓰는게 아니라 동일한 자격으로 CPU 경쟁을 벌인다.
프로세스와 스레드의 관계
JVM ← 프로세스
클래스 로딩
• main 스레드 → main() 호출
• 가비지 컬렉터 → 가비지 해제
가비지 컬렉터 스레드는 가비지를 메모리에서 해제시키는 작업을 한다. 메모리가 부족할 때 실행된다.
기타 등등 여러 개의 스레드가 있다
동시에 작업을 실행한다
JVM 안에 스레드가 몇 개 있는지는 나중에 확인하겠다
이게 바로 데이터를 공유한다는 거
여러 클라이언트가 실시간으로 데이터를 공유할 수 있구나
이게 바로 장점
이게 바로 데이터를 처리하는 기능을 별도 프로그램으로 분리시키는 이유다
4단계: 서버와의 통신 기능을 캡슐화
ScoreTableProxy 클래스 만들어서 캡슐화 하기
클라이언트는 메서드만 호출하면 됨
캡슐화
핸드폰 보드..
리튬 이온 전지 물 들어가면 폭발..
스피커 부분이랑 카메라 부분은 바깥에 공개
완전 공개할 건지, 일부만 공개할 건지 (공개 범위 조절)
그게 바로 private, protected, public ← 이게 캡슐화가 아님
캡슐화 한 다음에 그 캡슐 안에 있는 것에 접근
변수나 메서드를 클래스로 포장
어떤 코드를 메서드로 포장. 다시 그 메서드를 클래스로 포장한다.
포장을 한 다음에 그 메서드의 접근 범위를 조절할 때
private, protected, default, public
🔹 캡슐화 : 특정 기능을 수행하는 코드를 메서드나 클래스로 포장하는 것
포장함으로써 얻는 이점?
⟹ 복잡한 코드를 감추고 단순한 사용을 제공
util에 Prompt도 캡슐화임
promptString(), promptInt()
복잡한 코드를 포장시켜놓으면 쓸 때 편함
복잡한 코드를 메서드로 감추고 쓰는 입장에서는 아주 단순하게 쓸 수 있도록 단순한 사용을 제공
통신 기능을 캡슐화..
통신 규칙에 따라 데이터 입출력
ClientApp <------------------> ServerApp
통신 규칙에 따라 데이터 입출력상호 약속한 절차 = 프로토콜(protocol)
🔹 기존 개발 방식
프로토콜에 따라서 통신을 수행하는 코드를 작성
개발자A <---------------------> 개발자B
프로토콜에 따라서 통신을 수행하는 코드를 작성🔹 기존 개발 방식의 문제점
프로토콜이 바뀌면 그 내용을 Client 개발자도 숙지해야 한다.
🔹 변경된 개발 방식
Client에서 사용할 API 코딩
*.jar : Client에서 사용할 API
서버 개발자가 API를 만들면 클라이언트 개발자는 그 API를 사용하면 된다.
✓ 통신 부분의 코드가 캡슐화 되었기 때문에 네크워킹 코드를 작성할 필요가 없다
project-app2-server 가기
net 패키지 추가하기
ScoreTable을 복사해서 net 패키지에 붙여넣기
ScoreTable 이름 바꾸기 ---> ScoreTableProxy
ScoreTableProxy : ScoreTable 대행자
ClientApp에 있는 Socket, 입출력 스트림 코드 복사해오기
변수 미리 준비
생성자 만들기
public class ScoreTableProxy {
Socket socket;
ObjectOutputStream out;
ObjectInputStream in;
public ScoreTableProxy(String host, int port) throws Exception {
socket = new Socket(host, port);
out = new ObjectOutputStream(socket.getOutputStream());
in = new ObjectInputStream(socket.getInputStream());
}나중에 다 쓰고 닫을 수 있도록 public void close() 만들기
서버와의 통신 기능을 캡슐화 하는 거임. 코드를 감추는 거
client로 가서 ScoreHandler에서 create() 복사해서
ScoreTableProxy insert()에 붙여넣기
insert()에서 static 떼서 인스턴스 메서드로 바꾸기
out.writeUTF("insert");
out.writeObject(score);
out.flush();90-MyList프로젝트2 / 7 페이지
ScoreTableProxy, ServerApp, ScoreTable 를 서버개발자가 짜고
서버 개발자가 짜고
클라이언트 개발자는 서버 개발자가 만든 걸 사용해서 짠다.
캡슐화. 감추는 거
클라이언트 개발자는 어떻게 통신이 이루어지는지 모른다
그냥 RuntimeException 띄우며 좀 그래
ScoreTableException 클래스 만들기
ScoreTable에서 발생하는 예외는 ScoreTableException으로 하겠다
RuntimeException 상속받기
public class ScoreTableException extends RuntimeException {
serialVersionUID 기본적으로 포함되게 하기
생성자
RuntimeException 생성자가 여러 개임
서버의 ScoreTable을 다루다가 예외가 발생했을 때
그 상황을 직관적으로 알 수 있도록 별도의 서브 클래스를 정의하였다.
⇒ 즉 예외가 발생했을 때 예외 클래스 이름만으로도
어떤 상황에서 발생된 예외인지 바로 알 수 있도록 하기 위함이다.
insert()에 옮기기
static 떼기
서버 개발자가 짜고
클라이언트 개발자는 서버 개발자가 만들어 준 걸 사용해서 짠다
인스턴스 필드 쓰니까 static 떼기
// ScoreTableProxy.java
public Score[] selectList() {
try {
out.writeUTF("selectList");
out.flush();
String status = in.readUTF();
if (status.equals("success")) {
return (Score[]) in.readObject();
} else {
throw new RuntimeException(in.readUTF());
}
} catch (Exception e) {
throw new ScoreTableException(e);
}
}클라이언트 개발자가 했던 일을 서버 개발자가 가져옴
클라이언트 너는 내가 만든 거 쓰기만 해
.jar에 담아서 보낸다
classpath에 추가시켜서 사용한다
네트워크 관련된 내용은 찾아볼 수 없다
ScoreTableProxy에 감춰져 있다.
jdbc
JDBC 프로그래밍
DBMS 개요
DBMS : 데이터 관리 → 데이터를 파일에 I/O
데이터 테이블 → 테이블에 데이터를 보관
사용자 관리
사용 권한 관리
DBMS 전용 프로토콜 규칙에 따라서 소통해야 한다.
DBMS 클라이언트 제공
DBMS 통신 프로토콜과 Web 통신 프로토콜의 차이
DBMS Client ---------요청--------> DBMS Server
DBMS Client <---------응답-------- DBMS Server
DBMS 전용 프로토콜로 응답을 해야 하기 때문에
Oracle Client <--- O ---> Oracle Server
MS-SQL Client <--- O ---> MS-SQL Server
Oracle Client <--- X ---> MS-SQL Server
왜? DBMS 프로토콜이 다르기 때문에
웹 브라우저, 웹 서버는 달라도 접속 가능
프로토콜이 표준이기 때문에!
Web Browser ---------------> Web Server
표준 HTTP 프로토콜
Web Browser <--------------- Web Server
Safari Apache
Chrome IIS
Firefox NGINXMariaDB의 클라이언트와 서버
MariaDB 서버
.mysqld.exe (d: daemon - 서버)
MariaDB 클라이언트
mysql.exe
명령어 입력하고 엔터를 치면 서버가 응답한다.
직접 요청 불가!
App에서 MariaDB 서버에 직접 요청 불가
프로토콜 모른다 → 통신 불가능
프로토콜 안 알려준다. 중요한 서버 기술.
API를 제공한다.
JDBC API 라이브러리 제공
보통 라이브러리는 .jar 파일에 들어있다.
프로그램에서 MariaDB에
DBMS 전용 프로토콜을 개발자가 알 필요가 없다
① 명령
사용자 ------① 명령------> App.
② call
App. ------② call------> JDBC API 라이브러리
③ 요청 (DBMS 전용 프로토콜)
JDBC API 라이브러리 ------③ 요청-----> MariaDB 서버
④ 응답 (DBMS 전용 프로토콜)
MariaDB 서버 -----④ 응답-----> JDBC API 라이브러리
⑤ 리턴
JDBC API 라이브러리 -----⑤ 리턴-----> App.
⑥ 출력
App. -----⑥ 출력-----> 사용자
DBMS와 SQL
SQL : DBMS에 상관없이 표준적으로 사용할 수 있는 명령어 (작성 언어)
SQL(Structured Query Language)
표준 데이터베이스 질의 언어
요청을 할 때 통일된 요청 방법
Client에서 명령을 보낼 때
Oracle Client ------- SQL 명령문 전송 ------> Oracle DBMS
MS-SQL Client ------- SQL 명령문 전송 ------> MS-SQL DBMS
MySQL Client ------- SQL 명령문 전송 ------> MySQL DBMS
DBMS마다 약간씩 추가한 명령문이 있음 (+ ⍺)
표준 SQL만 쓴다면 상관 없는데 SQL이 완전 100% 표준만 사용할 수 없음
추가한 문법을 사용할 수 밖에 없음
100% 완전 표준이 아니기 때문에
/Users/nana/git/eomcs-docs/dbms/mariadb-settings.txt
