On Sat, Feb 24, 2001 at 06:02:48PM -0800, Jon Stevens wrote:
> > However, I actually disagree that this is bad engineering. At the level
> > that you are writing DB access code it shouldn't be important where the
> > DB connections come from and go, all you need to write semantically is
> > "i want a db connection" and "now I've finished with this connection". I
> > like the gain that you take the same code and it will work with either a
> > pooled or non-pooled connection provider.
>
> It is bad design to not use a pool for database connections. So it really
> doesn't matter that it is pooled or not pooled because 99.9999% of the time
> it will be pooled.
No disagreement that non-pooled connections is bad design.
That's not my point though, the point is that the app developer writing
the DB access code shouldn't even have to /think/ about the issue. They
just want to get a DB connection and let it go.
> The only case where I don't think you would use a pool is if you have a
> limited number of connections available (ie: due to licensing restrictions).
> In that case, should the specification of close() really have been
> overloaded? I don't think so. That method should have been @deprecated in
> favor of a properly named method (like releaseConnection()).
Yes, I'm not sure using the existing method named "close" was a great
choice. I can only guess this was decided because all the existing code
out there would have "finally { connection.close() }" at the end of the
DB access already. But like you say they could have overloaded close
_and_ deprecated it in favour of a better named method...
> > Either way if I commit Costas's changes (after testing) our user's get
> > to make their own choice ...
>
> That is fine with me. Just make sure you document it as well.
Okay, I'll update the docs that mention the pool to mention the JDBC2
way of doing it. Having said that its not strictly necessary because the
old ways will still work...
--
Sean Legassick
[EMAIL PROTECTED]
Jeg er mann: Ingenting menneskelig er fremmed for meg
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
