From: | Paul Thomas <paul(at)tmsl(dot)demon(dot)co(dot)uk> |
---|---|
To: | "pgsql-jdbc (at) postgresql (dot) org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: jdbc pooling question |
Date: | 2004-01-11 23:33:03 |
Message-ID: | 20040111233303.A15827@bacon |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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?
--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants |
http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+---------------------------------------------+
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2004-01-11 23:53:14 | Re: PreparedStatement parameters and mutable objects |
Previous Message | Ramin Rad | 2004-01-11 23:30:20 | Re: JDBC parse error with preparedStatement! |