On Sun, 11 Jan 2004, Paul Thomas wrote:
>
> On 11/01/2004 22:14 Kris Jurka wrote:
> > [snip]
> > Closing the connection will return the connection to the pool regardless
> > of the status of other related objects. The fact that closing the
> > statement and the connection doesn't completely close the ResultSet is a
> > bug, but not a terribly serious one. Adding a check for every single
> > method to check some kind of isClosed flag is tedious and wasteful.
>
> Plus there are a number of robust open-source connection pool
> implementations available. I use Apache dbcp (via Tomcat) and it all works
> very nicely and can also clean up resource leaks left by non-programmers
> who don't know how to correctly use a finally block :)
>
> OT, I can't really see the point of re-inventing the wheel by providing
> our own connection pooling. Does anyone else have any views on this?
Well, I wouldn't go out and write a new pooling system, but the one we
have at the moment only has what might be described as a very minor bug.
Supporting setLoginTimeout in the pool is a very simple addition, but the
problem is that what use is supporting it for the pool if the main driver
doesn't support it? Given that, it may be more consistent that it doesn't
work for the pooling case as well, although silently ignoring it may not
be the best idea.
Kris Jurka