[java web]DataSource와 Connection Pooling의 차이점과 장단점

목적

이 문서를 작성하는 목적은 지금까지 특별한 문제제기 없이 사용되어 왔던 DataSource와 Connection Pooling에 대하여 살펴보고자 한다. 최근에 DataSource를 이용하여 Connection Pooling을 사용하는 곳이 많은데 DataSource가 가지는 잇점이 무엇인지 살펴보도록 한다.

DataSource와 Connection Pooling에 대한 소개

Connection Pooling에 대해서는 부연 설명하지 않아도 대부분의 개발자들이 이미 알고 사용하고 있을 겁니다. 그러나 Connection Pooling을 지원하기 위하여 최근에는 DataSource를 사용하는 경우가 많다. 그렇다면 Connection Pooling과 DataSource는 어떠한 차이점을 가지며, 어떠한 장,단점을 가질까?

먼저 DataSource의 개념에 대해서 살펴보도록 하자. 아래 문서를 통하여 DataSource가 무슨 역할을 하는지에 대하여 이해할 수 있을 것이다.

• http://java.sun.com/j2se/1.4.2/docs/guide/jdbc/getstart/datasource.html (원서)
• http://xrath.com/devdoc/jdk1.5/ko/guide/jdbc/getstart/datasource.html (번역문)

DataSource API에서 설명하는 내용.

J2SE에서 제공하는 DataSoruce 클래스의 API 주석을 보면 다음과 같이 나와 있습니다. 이 글을 보면 DataSource에 대해서 이해하는데 도움이 될 것이다.

A factory for connections to the physical data source that this DataSource object represents. An alternative to the DriverManager facility, a DataSource object is the preferred means of getting a connection. An object that implements the DataSource interface will typically be registered with a naming service based on the JavaTM Naming and Directory (JNDI) API.

The DataSource interface is implemented by a driver vendor. There are three types of implementations:

Basic implementation – produces a standard Connection object 
Connection pooling implementation – produces a Connection object that will automatically participate in connection pooling. This implementation works with a middle-tier connection pooling manager. 
Distributed transaction implementation – produces a Connection object that may be used for distributed transactions and almost always participates in connection pooling. This implementation works with a middle-tier transaction manager and almost always with a connection pooling manager. 
A DataSource object has properties that can be modified when necessary. For example, if the data source is moved to a different server, the property for the server can be changed. The benefit is that because the data source's properties can be changed, any code accessing that data source does not need to be changed.

A driver that is accessed via a DataSource object does not register itself with the DriverManager. Rather, a DataSource object is retrieved though a lookup operation and then used to create a Connection object. With a basic implementation, the connection obtained through a DataSource object is identical to a connection obtained through the DriverManager facility.

DataSource를 사용하는 이점

온라인 상에서 이와 관련한 문서를 찾아보니까 제대로 정리된 문서가 많지 않은거 같다. 그나마 http://java.sun.com/j2se/1.4.2/docs/guide/jdbc/getstart/datasource.html 문서가 가장 잘 정리해 놓은 것으로 생각한다.

앞의 글들을 참고하여 DataSource를 사용할 때의 이점을 정리해보면 다음과 같다. 사실 특별한 이점은 찾지 못했지만 개인적으로 생각하는 부분을 정리했다.

• DataSource가 JDBC 2.0 스펙의 표준이므로 표준을 따를 수 있다. 표준을 따르는 것은 장기적인 관점에서 큰 이점이 될 수 있다.
• DataSource 표준에 Connection Pool을 지원하는 DataSource를 구현하도록 되어 있기 때문에 Connection Pool을 어떤 놈으로 사용할지 고민할 필요없이 WAS 벤더에서 제공하는 DataSource를 이용하면 된다. 프로젝트를 진행할 때 Connection Pool을 어느 것으로 사용할지 고민할 필요가 없다. 만약 WAS를 사용하지 않는 Stand Alone 프로젝트의 경우에는Jakarta DBCP를 이용하여 DataSource를 이용하는 것이 좋은 방법으로 생각된다.
• DataSource 표준에 분산 transaction를 제공하도록 하고 있다. 따라서 각각의 벤더에서 제공하는 DataSource를 사용하여 분산 Transaction을 지원할 수 있다.

• 이외에 이식성이 좋다는 이야기를 하는데 이 부분은 대부분의 DataSource 사용방법이 JNDI를 사용하기 때문에 생기는 이점으로 생각한다. JNDI를 이용하지 않을 경우에는 이식성은 Connection Pooling과 같을 것이라고 생각한다.

DataSource와 Connection Pooling의 실행속도 차이.

혹자는 DataSource가 더 느리다는 이야기를 하는데 이에 관해서 검증단계를 거치지 못했다. 이 두가지의 실행속도를 비교한 문서가 있으면 첨부해 주기 바란다.

이 문서에서 첨부한 문서외에 더 좋은 문서나 DataSource의 이점이라고 생각하는 부분이 있다면 추가해 주시면 좋겠습니다..