Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 464 invoked from network); 8 Jan 2002 21:00:03 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 8 Jan 2002 21:00:03 -0000 Received: (qmail 14708 invoked by uid 97); 8 Jan 2002 21:00:07 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 14692 invoked by uid 97); 8 Jan 2002 21:00:07 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 14678 invoked from network); 8 Jan 2002 21:00:06 -0000 Sender: jmcnally Message-ID: <3C3B5D18.40D5FA16@collab.net> Date: Tue, 08 Jan 2002 12:56:56 -0800 From: John McNally X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: commons-dev@jakarta.apache.org Subject: torque and my work on its connection pool. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I guess there has been some discussion on whether commons should come up with an alternative to torque or whether torque should be moved to commons. I am unclear on why torque is unsatisfactory due to its current location. I will have read up on that discussion, if anyone has useful pointers to the discussion in the archive that would be great, otherwise I will find them. But I will take a moment to describe my work on updating torque as this work seems to have come up in an validation framework thread. Torque currently relies on an internal connection pool. I would like that this reliance dependence be broken, so i looked at the jdbc2 api regarding connection pooling and decided to adopt it for use in torque as that should maximize the number of pools available. So for torque the part of the jdbc2 api that is relevant is 1. The connection is retrieved through DataSource.getConnection 2. The connection is returned (or disposed of) through Connection.close() It is possible the commons dbcp package meets these requirements and so it could be used with torque. I looked at dbcp and it did not seem to be jdbc2 compliant. In looking at the pool it had many classes, so the design was difficult for me to get a handle on. I opted instead to make torque's connection pool jdbc2 compliant. As torque's cp was two classes this seemed like a much easier task. Actually it turned out to not be that simple (but it is still two classes), so in hindsight maybe I should have taken the additional time to figure out the commons dbcp and then try to become a member of the commons and push through an upgrade of the dbcp to the latest jdbc api. Are the maintainers of the commons dbcp interested in updating their pool to be jdbc2 (or 3) compliant? I think they would be well served by looking at the work I have done on torque's dbcp. I will post a link to the files if they are interested. I created an adapter for use with jdbc drivers that do not implement the latest api that would likely be useful if and when the commons dbcp was updated. john mcnally -- To unsubscribe, e-mail: For additional commands, e-mail: