DB 커넥션 풀

1,043 views
Skip to first unread message

은메달

unread,
Nov 2, 2012, 4:55:56 AM11/2/12
to ks...@googlegroups.com
KSUG 여러분들은 DB 커넥션 풀을 사용할때 어떤 라이브러리를 사용하시나요?

대표적으로 apache commons DBCP, mchange(엠창? 엠체인지? 알고보니 Machinery for change 라는 멋진 의미 였음ㅋㅋ) c3p0 가 있고,
BoneCP 라는 것도 있더군요. 저로서는 써본 적 없는...

그리고 각 DBMS 벤더 별로 자체 개발한 커넥션 풀도 존재 하기도 하구요..


저는 여지껏 진행한 프로젝트 중 단 2건만 c3p0 를 사용했고, 나머지는 모두 DBCP 였습니다. DBCP 가 더 좋아서 쓴건 아니고 apache commons 라이브러리에 친숙하다보니 그런것 같네요.


대표적인 두 커넥션 풀 두개 중 뭘 쓸지에 대한 고민은 많은 개발자의 이슈였는지, 검색해보면 여러 자료들이 나오더군요.

이 글 저글 읽어 보다 보니 나오는 결론은 

단일 쓰레드 환경이라면 DBCP 성능이 좋고
다중 쓰레드 환경이라면 c3p0  성능이 좋다

왜? 왠지는 검색해보면 나오는 자료가 이유 ㅋㅋㅋㅋ 소스를 까고 눈으로 봐서 확인해야 겠지만 귀차니즘으로 OTL

KSUG 그룹스 주제 검색해 보면 관련된 포스팅이 많은데 그 중 2009년 쯤에 올라온 주제를 보면 DBCP 의 버그 사항과 그게 해결 되지 않는 문제로 까임을 당하는 걸 볼 수 있었습니다.

그럴만 한 것이 DBCP 가 2007년 이후로, 업데이트가 뜸했으니...

근데 2010년 화이트 데이 때 1.4 버젼이 나오면서 여러 버그가 많이 수정되었습니다. (http://commons.apache.org/dbcp/changes-report.html) 그간의 까임을 좀 피할 수 있을법 한...


저도 DBCP 로 골머리 썩은 적이 있었습니다. 2008년 경에 진행했던 프로젝트에서 틈만 나면 커넥션 풀의 커넥션이 동나 버리는 현상이었던 것 같은데.
실질적으로 코딩을 담당했던 프로그래머가 자원의 반환이라는 개념을 제대로 탑재하지 못했던 것이 원인으로 나중에 결론이 났자만, 
그 당시 해결은 removeAbandoned 이라는 프로퍼티를 활성화 시켜서 해결했던 것 같네요. 돌아오지 못한 넘은 버려라 라는 의미를 가진 놈이 었는데, 그냥 라이브러리 가져다 그냥 고대로 쓰니 장애가  터지고 나서야 알게 된 것이었습니다.

즉, 커넥션 풀이 DBCP 인지 c3p0 인지의 문제 보다, 속을 제대로 들여다 보지 않는 것이 더 큰 문제 였던 것이지요.

글을 쓰다보니 주접이 된 것 같은데, 이 글을 쓴 계기는 바로
근래 어느정도 완성된 웹어플리케이션에 대한 추가 개발을 맡게 되었는데, 뜯어 보니 c3p0 를 사용하고 있더라구요.
너무 오랜만에 보는 c3p0 이기에, DBCP 와 비교, 튜닝 포인트 같은 것들에 대해 검색질을 해대다가, 
저에게 정말 많은 정보를 주시는 KSUG 여러 개발자분들 깨서는 어떤 걸 쓰시는지, 
그리고 관련된 정보를 좀 공유 해보고 싶어서 입니다. 해보고 싶어서 보다는 공유 좀 해주십사 겠죠 ㅎㅎ

아. 그리고 statement pooling 기능을 사용하시는 지요? 사용하고 계시다면 별 문제 없는지 궁금합니다.

금번 c3p0 를 사용하길래 statement pooling 기능을 활성화 시키려다가 API 문서를 통해 DBMS Oracle 일 때, 데드락을 유발할 수 있다는 커멘트를 보고 일단 보류하고 있습니다.
0.9.2-pre5 버젼에서는 statementCacheNumDeferredCloseThreads 프로퍼티를 통해 해결 가능한 듯 한데, 일단 제가 맡고 있는 웹 어플에서 사용하는 c3p0 버젼은 0.9.1.2 라 해당 프로퍼티가 없네요...

YongHyuk Lee

unread,
Nov 2, 2012, 6:24:10 AM11/2/12
to ks...@googlegroups.com
사용하는 WAS JNDI 사용.

나의 iPhone에서 보냄

2012. 11. 2. 17:56 "은메달" <miro...@naver.com> 작성:

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
웹에서 이 토론을 보려면 https://groups.google.com/d/msg/ksug/-/v5z2RV7pQbAJ을(를) 방문하세요.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

KwonNam Son

unread,
Nov 4, 2012, 1:06:53 AM11/4/12
to ks...@googlegroups.com
BoneCP 소개 감사합니다. 성능이 매우 좋네요.

저희는 그냥 가장 많이 쓰이는 DBCP를 사용하지만, Connection Pool은 그 특성상 갈아끼우기가 매우 쉬우므로 이래저래  테스트해볼만한 가치가 있어보입니다.

BoneCP 테스트 해봐야겠습니다.



2012년 11월 2일 오후 7:24, YongHyuk Lee <unlogi...@gmail.com>님의 말:



--
* 까먹지말자! http://kwon37xi.egloos.com

미랭군

unread,
Nov 4, 2012, 11:46:33 PM11/4/12
to ks...@googlegroups.com

먼저 Tomcat DBCP Connection Pool 이 commons DBCP 보다 좋은 점이 뭔지에 살펴보자.

이 내용은 아파치 홈페이지에 있는 내용 중 몇 가지만 추린 내용이다.

http://people.apache.org/~fhanik/tomcat/jdbc-pool.html

 

- 새로운 dbcp 를 써야하는 이유

: commons dbcp 는 싱글 쓰레드를 사용한다. 그래서 스레드가 안전할 수 있도록 commons dbcp 는 전체 풀(pool) 에 대해서 롹(lock)을 건다.

: commons dbcp 는 느리다. 요즘 하드에워는 cpu 수가 증가하고 있는데 반해서 이를 제대로 활용하고 있지 못해서 퍼포먼스가 떨어진다.

: commons dbcp 는 복잡하다. 클래스 수가 60개나 된다. 반면, tomcat jdbc pool 은 딸랑 8개 이다. 이는 수정이 용의함을 의미한다.

: commons dbcp 는 정적인(static) 인터페이스(interface) 를 사용하기 때문에 구현 되지 않은 모든 메소드들에 대해서 예외(exception) 을 받게 될 수 있다.

: commons dbcp 는 상당히 업데이트 되지 않는다 ..

: tomcat jdbc pool 은 commons dbcp 에서 제공하지 않는 기능을 제공하면서도 빠르다.

: 추가적인 스레드를 더할 필요 없이 connection 을 비동기적(asynchronously) 회수할 수 있도록 구현할 수 있다.

 

- 추가된 기능

: 현재의 높은 멀티코어 환경을 충족시킨다.(혹은 제대로 활용한다??)

: inteface 의 동적인(dynamic) 구현(??)

: validation interval 을 설정해 줄 수 있다.

: 높은 퍼포먼스

: 간단해서 버그잡기가 용의. 핵심 클래스는 8개 뿐

 

- 단점

: 디비가 다운되었을 때, 재 연결을 위해서는 웹서버를 내렸다가 올려야 한다.(아무래도 미리 커넥션을 맺어둬서 그런 듯^^?)

Reply all
Reply to author
Forward
0 new messages