I've never used connection pooling so bear that in mind... connection
pooling is best suited for situations where there are many clients that use
the DB for short, well defined requests with lots of idle time inbetween
(that's what the book I read said anyway). Intuitively, a connection pool is
just mimicing a DB to the client anyway, so if you don't explicitly close
connections in your own code, how can your connection be returned to the
pool (assuming the process doesn't terminate)?
No matter what the standard or implementation document says about it's
management of connections, I would still require my programmers to
explicitly close connections when the application is fnished with them. It's
simply good programming practice, and at least that way, if a problem with
connection memory leakage occurs you can blame someone else.
If I missed the point here, I stand ready to be educated.
Regards,
Iain
> >> In the JDBC API Tutorial and Reference, it suggests that driver
> >> implementors assume the worst, so I think that we should attempt to
> >> clean up our clients connections as best we can.
