From jmcnally@collab.net Thu May 9 16:10:07 2002 Return-Path: Mailing-List: contact db-help@apache.org; run by ezmlm Delivered-To: mailing list db@apache.org Received: (qmail 44665 invoked from network); 9 May 2002 16:10:07 -0000 Received: from ar1-nat-sp.collab.net (HELO dhcp24) (63.251.56.5) by daedalus.apache.org with SMTP; 9 May 2002 16:10:07 -0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dhcp24 (Postfix) with ESMTP id 1249B441EA for ; Thu, 9 May 2002 09:10:10 -0700 (PDT) Subject: Re: Status From: John McNally To: db@apache.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 09 May 2002 09:10:09 -0700 Message-Id: <1020960610.1931.32.camel@dhcp24> Mime-Version: 1.0 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Thu, 2002-05-09 at 05:33, Geir Magnusson Jr. wrote: > 2) Poolman - popular database connection pooling package, currently at I would like to move Jdbc2Pool, currently in the commons/sandbox, here as well, with or without DBCP. Jdbc2Pool includes a simple pool that was pulled from Torque into a freestanding DataSource implementation. It also contains a more full featured DataSource based on commons-pool similar to db pools found in DBCP. It also contains an adapter to jdbc1 Drivers that uses the PreparedStatement pooling found in DBCP. The main difference between Jdbc2Pool and DBCP or Poolman is that Jdbc2Pool, as its name implies, attempts to fully comply with the specification. DBCP and Poolman can both present DataSource frontends to the applications that use them (at least I think Poolman has that.) However their internal organization and how they interact with the jdbc driver implementation is based on jdbc1. I think a connection pool based on the latest (jdbc3 is not that different from jdbc2 wrt to pooling connections) is a good thing to continue to develop even if Poolman is created as a top level subproject of db.apache.org. I guess I don't see why a simple thing like a connection pool should exist as a top level project. It only needs to be a handful of classes. I think a better location is db/commons or db/tools. john mcnally