Hello Scott, There is another connection pool located in commons-sandbox/jdbc2pool that behaves as you expect, multiple lookups of the same pool will NOT reset the pool. Jdbc2pool is written to use a ConnectionPoolDataSource as the backend providing the connections. It does have an adapter package that can be used with the older Driver style of providing physical connections. This adapter adds the benefit of PreparedStatement pooling as well. Jdbcpool has not been put to the test in a production system yet, but it does pass its tests and is based on the same commons-pool code used in BasicDataSource.
john mcnally Scott Jones wrote: > > Hi Chad, > > Didn't get your emails until this morning -- are you experiencing the > same problems that I was talking about? Basically, it seems like a new > connection pool is getting set up after every JNDI lookup (which I'd > basically like to do every time I run a query). If I hold on to the > same datasource, I can see that it's obvious that connection pooling is > working... > > I've just been doing something like the following the code below to test > it out. However, the thing that I notice is that rerunning this code > doesn't hold on to the original pool -- in the following code segment > the first and second connections are always > 50ms to get and the last > one (which comes from the pool) is always around 0-1ms. It seems to me > that the DataSource should get "cached" or held on to in some way -- > Otherwise, it seems like it's defeating the purpose of connection > pooling!!! -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
