on 2/24/01 5:45 PM, "Sean Legassick" <[EMAIL PROTECTED]> wrote:
> Yeah, I do see your point - you look at a call to close() and you don't
> know whether it will close or release the connection.
Bingo.
> 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.
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()).
> 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.
-jon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
