조금 찾아보다 보니 OID나 Collection같은 특성을 사용하기 위해서는 DBCP를 못쓰는거 같네요...
보니까 브로커 개념이 있던데. 이녀석도 중간에 자원관리를 해주는 역활을 하나 보네요.
어차피 브로커가 있다면 DBCP도 크게 커넥션수같은 DB자원 사용량을 줄이는 정도가 적을거 같기도 한데...
OID를 쓰면서 join이나 서브쿼리가 줄어드는 효과와, DBCP를 사용못해서 늘어나는 자원사용량을
어떻게 판단하면 좋을지 의견좀 부탁드립니다.
현재 왠만한 DB모델링에서도 OID나 Collection개념을 포함해서 모델링되는 경우가 거의 없어서
잘 확신이 들지 않네요.
모델링 하면서도, 이렇게 한다고 해서 효율적일까 하는 의문이 계속 들더군요.
CUBRID의 object 특성을 사용하는 것과 DBCP는 연관성이 많지 않습니다.
oid나 collection을 사용한다는 것은 두가지 관점에서 볼 수 있을것 같습니다.
1. 모델링 & 쿼리
간단히 예를 들어 사원 테이블과 부서 테이블이 있다고 가정할떄,
관계 모델에서는 사원 테이블에 부서 코드 컬럼을 추가하고, 사원 테이블과 부서 테이블을 조인하여 원하는 결과를 얻는 형태가 될 것입니다.
object 를 활용할 경우에는 사원 테이블에서 부서에 대한 object를 가지게 되고, 조인없이 path expression을 활용하는 형태가 될 것입니다.
이 경우는 확장된 SQL을 통해서 object에 대한 접근을 하게 되므로,
개발 관점에서는 스키마의 변경과 쿼리의 변경이 있게 됩니다.
JDBC 인터페이스를 그대로 사용하게 되므로 dbcp를 사용하는것과는 연관이 없습니다.
2. 확장 api
확장된 메소드를 사용하기 위해서는 dbcp가 만든 connection이나 satement 객체 내에서 드라이버가 만든 object를 꺼내기 위해 몇가지 단계를 거쳐야 하는 불편은 있습니다.
이렇게 OID에 대한 확장된 메소드를 사용하는 경우는 한번 접근한 객체에 대해 반복적인 읽기/쓰기를 직접 수행하는 것이 효율적인 응용의 경우 적합합니다. 웹 서비스의 경우에는 한번 접근한 데이터를 다시 사용하게 되는 경우가 많지 않기 때문에 굳이 사용할 필요가 없다고 보입니다.
두가지 관점으로 볼떄 현재 필요한 부분이 모델링과 확장된 쿼리가 아닌가 생각됩니다.
이 경우에는 dbcp를 사용하는데는 문제가 없을것으로 생각되지만,
이렇게 활용된 레퍼런스가 많지 않다는 점은 향후 적용하는데 어려움은 될 수 있을 것 같습니다.
DBCP를 사용하는 경우 OID 등의 CUBRID 특성 기능을 사용할 수 없습니다. 따라서 OID 등을 사용하는 경우에는 별도의 Pooling 을 구현하셔야 합니다.
Broker가 존재하더라도 응용에서 Broker까지 connection을 맺기위한 비용을 생각해볼때 DBCP 등의 connection pool 사용하시길 권장합니다.