CUBRID의 Statement pooling기능

 JDBC 응용프로그램에서 Application 의 성능향상을 위해 Connection Pooling을 많이 사용한다. JDBC응용 프로그램과 DBMS 사이에 Connection 이 빈번하게 발생하면 실제로 질의를 처리하는 시간에 비해서 응용 프로그램과 DBMS 사이의 연결을 맺고 끊는데 많은 시간이 필요하기 때문이다. 대표적으로 Apache Project의 DBCP를 보면, 한번 맺은 Connection 을 재사용할 수 있도록 해준다. DBMS가 사용자가 입력한 SQL Statement을 처리하는 과정을 살펴보면, Connection Pooling 이 필요한 이유와 비슷한 이유로 Statement Pooling 이 필요하다는 것을 알 수 있다. CUBRID에서의 Statement pooling기능에 대해서 소개한다.

1.CUBRID Client 모듈에서 SQL Statement 의 처리
 - DBMS가 SQL을 처리하여 결과를 만들어 내는 과정은 아래와 같은 단계를 거친다.

  SQL 입력 -> SQL Parsing -> Query Optimize -> 질의 수행 계획 작성 -> 질의 수행 -> 질의 결과

 - CUBRID 의 경우 Client 모듈과 Server 모듈로 분리되어 있고, Client 모듈이 질의 수행계획을 작성하는 것을 담당하고, Server 모듈은 작성된 수행계획을 수행하여 질의 결과를 생성하는 것을 담당한다.
 - 사용자가 SQL을 입력했을 때 Client 모듈이 하는 일을 아래와 같다.

  SQL Parsing : 입력된 SQL 문장에 대한 Syntax check 과 semantic check 을 수행하고 수행 결과로서 Parse Tree 를 생성한다.

  Query Optimizer : Parse Tree를 입력으로 받아 질의를 수행하는 비용이 작게 들도록 질의를 최적화 한다.

  질의수행계획작성 : CUBRID는 Parse Tree를 입력으로 받아 CUBRID 서버가 질의를 수행하기 위한 실행 계획 Format 인 XASL 을 생성 함.

 - 사용자가 임의의 SQL 문을 입력하면 위와 같은 과정이 되풀이 되고, 서버는 XASL 을 받아서 질의를 수행한 후 그 결과를 만들어 낸다.
 - 아래와 같은 질의를 연속적으로 수행한다고 가정해 보자.

  select * from history;

 - 위 질의가 수행되려면, 문장을 Parsing 하여 Parse Tree를 만들고, 질의 최적화를 수행하고, 질의 수행 계획을 만들어서 DB서버에 전달하여야 한다. 프로그래머가 다시 위의 질의를 수행하려면, 다시 Parsing, 최적화, 질의 수행을 다시 만들어야 한다. 같은 질의에 대해서 Parse Tree와 질의 수행 계획을 재 사용할 수 있다면, 클라이언트 모듈에서 발생하는 부하를 줄일 수 있다.

2.Statement Pooling
 - SQL Statement 를 Parsing 하고, 질의 수행계획을 만드는 것을 Statement Compile이라 하고, Compile된 Statement 를 재사용하기 위해 Statement를 Pooling하는 것을 Statement Pooling이라고 한다. 새로운 Statement 가 입력으로 주어졌을 때에는 해당 Statement를 새로 Compile 하여 사용하며, 사용이 끝난 Statement 는 Pool에 반환한다. Pool에서 관리되는 Statement 들은 다시 Prepare하지 않고, Prepare 시 반환된 Statement 의 Handle 값을 사용해 바로 Execute를 수행할 수 있음으로 Prepare 과정을 생략할 수 있다.
 - CUBRID 에서 Statement 를 Pooling을 관리해 주는 Process는 cub_cas 이며 CAS(Common Application Server) 라고 불리고 있다.

3.CUBRID 에서 Statement Pooling 기능의 사용.
 - CUBRID 에서 Statement Pooling 기능을 사용하기 위해서는 cubrid_broker.conf의 옵션에 다음의 옵션을 추가해야 한다.

 STATEMENT_POOLING = ON

 - 해당 옵션을 변경한 후에는 반드시 CUBRID broker 를 restart 해야 한다. Statement pooling 기능을 사용하기 위해서 별도로 JDBC를 사용하는 프로그래머가 해야 할 일은 없다.
 - Statement Pooling 기능과 관련하여 CUBRID가 가지는 특징이 있는데, CUBRID 의 Statement 는 Connection 에 종속적이며, 해당 Connection 에서 수행중인 Transaction이 commit 되거나 rollback 되면 그 Connection 에 있는 Statement 들이 close 되는 특징이 있다. CUBRID를 사용하여 JDBC 응용프로그램을 작성하는 프로그래머는 가끔씩 “Attempt to access a closed Statement” Exception 을 보게 되는데, commit 이후에 해당 Connection에 있던 Statement를 사용하려 했기 때문에 발생하는 경우가 대 부분이다. 이는 CUBRID Statement는 Transaction이 정리될 때 같이 정리된다는 사실을 잘 알지 못하고 프로그램을 작성하기 때문에 나타나는 현상이며, 이를 해결하기 위한 하나의 방법이 Statement Pooling 기능을 사용하는 것이다. Statement Pooling 기능을 활성화 시키면, JDBC와 CAS에서 commit이나 rollback 을 수행할 경우에 Statement를 close 하지 않기 때문이다.

4.CUBRID의 Statement Pooling 은 언제 사용해야 하나?
 - CUBRID의 Statement Pooling 옵션은 응용프로그램의 입장에서 Statement 를 재사용 할 가능성이 있으면 ON으로 하는 것이 좋다. (활성화 하지 않는다면 “Attempt to access a closed statement” Exception 을 만나게 될 것이다.) 특히, DBCP 와 같은 Connection Pooling을 구현해 주는 Library를 사용한다면 기본적으로 Statement 를 재 사용하려고 할 것임으로 옵션을 반드시 켜 주어야 한다.

참조: http://blog.naver.com/decay97/70051586945