CUBRID CAS의 구조 및 동작방식.txt

CUBRID CAS는 CUBRID 데이터베이스를 사용하는 클라이언트들(웹 응용 등)이 CUBRID 데이터베이스 서버에 연결할 수 있게 해주는 미들웨어입니다.
1. 구조
위 그림 참조

2. 구성요소 동작방식
- Broker
Broker는 ODBC, JDBC, PHP등의 인터페이스를 통한 클라이언트의 요청을 응용서버(cas)에게 전달하는 역할을 수행합니다. 클라이언트로부터 요청이 들어오면 Broker는 Shared Memory를 통해서 쉬고 있는 cas를 찾아서 요청을 전달하고, 요청에 대한 처리가 끝난 후 결과를 클라이언트에게 넘겨줍니다. 또한 Broker는 cas가 비정상 종료되었거나 프로세스 크기가 설정한 크기보다 크다면 재구동 시키는 등 cas들을 관리합니다.

- Shared Memory
Shared Memory는 cas의 상태 정보를 가지고 있다가 Broker에게 그 정보를 제공합니다.

- Service Pool
Service Pool은 Broker에 의해서 관리되는 cas의 그룹입니다. 클라이언트로부터 요청이 cas로 전달되었을 때 이전 클라이언트의 요청에 의해 데이터베이스 서버로 연결되어 있었다면 cas는 클라이언트의 요청을 바로 처리하기 시작합니다. 그러나 아직 데이터베이스와 연결되어있지 않았거나 다른 데이터베이스 서버와 연결되어 있었다면 cas는 원하는 데이터베이스로 연결을 시도합니다. 이와 같은 Service Pool 기능 덕분에 타 DBMS 사용하는 어플리케이션에서 따로 구현하는 Connection Pool을 클라이언트에서 따로 구현하지 않아도 됩니다.

3.CUBRID CAS는 위와 같은 구조 및 동작방식에 의해 클라이언트의 요청을 처리하게 됩니다. 시스템 자원은 한정되어 있기 때문에 클라이언트의 요청 처리를 담당할 cas의 수를 무한히 늘릴 수는 없습니다. 이에 따라 효율적인 운영을 위해서 cas의 수는 일정하게 유지되는데 클라이언트 하나의 요청이 장시간 cas에 할당되면 다른 요청이 cas를 통해 서비스를 받을 수 없게 되어 원활한 서비스가 이루어지지 않게 됩니다.
cas는 질의 수행시 그에 대하여 commit이나 rollback이 올 때까지 다른 요청을 받지 않고 해당 사용자의 요청만 받게 됩니다. 따라서 사용자는 질의처리 후 최대한 빨리 commit/rollback 처리를 통하여 transaction을 종료시켜주어야 합니다. CUBRID는 select 만 하더라도 transaction의 시작으로 간주하여 commit/rollback을 기다리도록 되어있으므로 일반적인 상황에서는 auto commit을 on(default)으로 하시고, insert/update/delete 등의 상황에서만 auto commit을 off로 설정하여 transaction을 관리해주는 것이 효율적입니다.

- 출처 - 큐브리드 홈페이지