Contents

• 좌절 아닙니다.
• 메인 링크 : http://otl.sourceforge.net
• oracle 및 ODBC 관련 연결을 C++상에서 손쉽게 구현해주는 라이브러리. 템플릿으로 제작되어있고 단지 헤더화일 하나라는 것이 특이하다. 그러므로 C++을 지원하는 거의 모든 플렛폼에서 사용가능하다는 것이 장점.

• unixodbc는 2.2.9-1 rpm을 설치하는 것이 좋다. 물론 devel도 같이 설치한다.
• MyODBC도 역시 최신판을 설치한다.
• 컴파일시 다음과 같이 #define이 되어있어야한다.

  #define OTL_ODBC
  #define OTL_ODBC_UNIX
  

OTL 스트림 풀링은 비효율적으로 관리되는 otl_stream 객체들을 성능을 고려하는 한도내에서 보다 더 나은 무언가로 변환하도록 하기위한 새로운 체계입니다. otl_stream 인스턴스들은 닫히게 될때 차후 재사용을 위해 stream 풀 내에 저장됩니다. 일반적으로 프로그램상에서는 함수안에 지역적으로 otl_stream 변수를 선언하는 것이 더 사용하기 편리할 수 있습니다. 이럴 경우 함수가 반복적으로 호출될 때 마다 스트림은 인스턴스되고 닫히는 것을 반복하게 됩니다.

스트림을 매번 인스턴스화하는 것은 스트림의 SQL 문장을 다시 파싱하도록 데이타베이스 backend에 지시하게 됩니다. 이는 비교적 비용이 많이 드는 명령입니다. 스트림 풀링 장치는 이러한 부담을 줄여주고 코딩을 단순하게 만들어줍니다.

스트림 변수가 닫힐 때, 실제 otl_stream 인스턴스는 스트림 풀 내에 저장됩니다. 그런 다음, 비슷한 OTL 스트림 요청이 들어오면 OTL 스트림 변수는 함수에게 선언된 지역변수이건, 힙에 선언된 변수이건간에 선언된 otl_stream 변수에 대입됩니다. 스트림들간의 비슷하다라는 기준은 (스트림버퍼크기+SQL문자열)로서 정의되며, 이것은 같은 버퍼크기와 동일한 SQL 문장을 가진 스트림은 스트림 풀의 같은 저장공간에 저장될 것이라는 것을 의미합니다.

Say, three instances of similar streams of <buf_size1+SQLStm1> were allocated and then all of them were closed. The pool will have one entry point for all the three and the actual bodies of the instances will be placed in the same bucket (see the diagram below). After that, the functions, in which the streams had been created, get called on the second iteration of a loop, and the corresponding otl_stream variables get instantiated again. The second time around, the instances of the similar streams, which were previously saved in the pool, will be pulled out of the pool and re-assigned to the variables, until the variables get closed again.

In some cases, an instance of a stream, if it is, say, used only once, can bypass the pool and be destroyed without saving it in the pool. The otl_stream::close() function has extended functionality to allow the developer to do that.

If the stream pooling is undesirable, then the OTL code, which implements the pooling, can be turned off (not turned on at all). This is controlled by a conditional compilation directive, since OTL is a C++ template as well as macro library with a lot of conditional compilation directives in it, for efficient code generation.

The stream pool has a fixed maximum size, that can be changed by the otl_connect::set_stream_pool_size() function. And, as it already should be obvious from the description above, the stream pool is a property of the otl_connect object.

The implementation of the stream pool was made with the help of STL containers, maps and vectors in particular. Therefore, #define OTL_STL needs to be enabled in order to turn on the OTL code in the STL compliance mode.

From the statistic that I (Sergei Kuchin) was able to gather, the stream pooling has very little overhead (2-4%), compared to the use of otl_stream's, which are kept open always, and don't get closed. This is due to the fact that the std::map<>, as an STL data container, is performant enough.