Re: pooled connection myth
From: David McDivitt (x12code-del_at_del-yahoo.com)
Date: 03/17/05
- Next message: Lee Fesperman: "Re: pooled connection myth"
- Previous message: VisionSet: "Re: New job and I want to change the world..."
- In reply to: John C. Bollinger: "Re: pooled connection myth"
- Next in thread: Lee Fesperman: "Re: pooled connection myth"
- Reply: Lee Fesperman: "Re: pooled connection myth"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 17 Mar 2005 13:21:56 -0600
What I'm trying to do is establish some arguments to do things differently.
Just because a package says something does not mean it really does that. The
package may only be presenting an abstract idea. Some people believe
applications should be built with ultimate conceivable robustness in mind,
always, with however many unused pieces to facilitate the idea. I do not
agree with that. Just because a new gimmick infers robustness does not mean
it should be used on that basis alone. The applications we have where I am
have too many of these and code cannot be followed for maintenance.
>From what I've seen I see no reason for connection pooling under any
circumstance, even if it was working. A connection manager should return one
of three or four shared connections. An additional method should be present
which returns a standalone connection for times when such might be needed
for tran blocks, etc. Anything beyond this is just more bloated java crap.
>From: "John C. Bollinger" <jobollin@indiana.edu>
>Subject: Re: pooled connection myth
>Date: Thu, 17 Mar 2005 12:31:47 -0500
>
>David McDivitt wrote:
>
>> There is much to be gained by reusing known open connection objects, rather
>> than issuing single use connection objects for each request. If connection
>> objects are not modified by using transaction blocks, there's no reason not
>> to share them between threads.
>
>This may vary from driver to driver. In any case, however, you cannot
>assume that a user of the Connection will *not* use transaction blocks,
>so even if that were the only consideration you could not safely share
>Connections concurrently among threads.
>
>> The word "pooling" implies this, but pooling
>> itself doesn't do very much.
>
>I'd say that "pooling" implies the opposite of sharing Connections
>concurrently among threads. If it were safe to share Connections in
>that way then there would be no need for a pool. Pooling implies need
>(or at least use) for multiple interchangeable instances.
>
>> For the most part, all that happens is caching
>> the database user name and password.
>
>You can't have it both ways. You earlier defined what you mean by
>connection pooling, and very emphatically excluded simple credential
>caches that do not reuse Connections. I think we all agree with you
>that such mechanisms are not connection pools. When used appropriately
>pooling does what it's advertised to do, which is reduce the number of
>separate connections made to the database by using a few connections to
>support multiple connection users.
>
>So, do some applications make use of non-pooled connections? Of course.
> Do other applications make use of connection pools? Absolutely. Can
>junior developers to be confused about whether connection pooling is in
>use or not? Yes. Is connection pooling useful? Sometimes.
>
>Do you have a further point?
- Next message: Lee Fesperman: "Re: pooled connection myth"
- Previous message: VisionSet: "Re: New job and I want to change the world..."
- In reply to: John C. Bollinger: "Re: pooled connection myth"
- Next in thread: Lee Fesperman: "Re: pooled connection myth"
- Reply: Lee Fesperman: "Re: pooled connection myth"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
