Re: temporary tables and connection pooling

[Kristian Waagan <Kr...@Sun.COM>]

Bob Durie wrote:
> Thanks for the comments!
> 
> I wouldn't even know where to begin to implement a master procedure to
> do this work, efficiently anyways.  I could name my tables in a known
> scheme, search the table lists, then drop if they exist, but that is
> computationally expensive.  I think a better approach would be to do it
> in my java persistence layer, whenever I fetch a temp table, record the
> connection that got it, then when I give it back to the pool drop it by
> name.
> 
> As for the ConnectionPoolDataSource - I didn't even know this existed!!!
> We are using physical/logical connections using
> org.apache.commons.pool.impl.GenericObjectPool and after a first glance
> it seems to be MUCH MORE feature rich, supporting testOnBorrow/Return,
> idle timeouts, maxActive, etc..  I may give this other pooling scheme a
> shot, but for fear its support may not be across the board for other
> db's (we also use SQL Server and Oracle) I will likely have to go with
> the track n slash approach.  PLEASE correct me if you think I'm wrong
> here.

At least for Derby, you still need a connection pool manager on top of
the ConnectionPoolDataSource. This manager could provide the other
functionality you refer to. Note that to get a connection intended for 
pooling, you must call 'getPooledConnection'.

I don't have much hands-on experience with this, but I have been using
ClientConnectionPoolDataSource with the Glassfish connection pool.
There were some performance problems with the implementation, they have 
been fixed in the development versions by now.


If you try it out, let us know how it goes :)



hth,
-- 
Kristian

> 
> Bob
> 

[ snip ]