Mark Pritchard wrote:
>>I think it is the startup cost that most people want to avoid, and our's
>>is higher than most db's that use threads; at least I think so.
>>
>>It would just be nice to have it done internally rather than have all
>>the clients do it, iff it can be done cleanly.
>>
>
> I'd add that client side connection pooling isn't effective in some cases
> anyway - one application we work with has 4 physical application servers
> running around 6 applications. Each of the applications was written by a
> different vendor, and thus a pool size of five gives you 120 open
> connections.
Tuning a central pooling mechanism to run well in this kind of situation
isn't going to be a trivial task, either. The next thing you'll want is
some way to prioritize the various clients so your more serious
applications have a better chance of getting a pool.
Or you'll want to set up subpools so they don't compete with each other,
in effect replicating what's done now, but adding more complexity to the
central service.
--
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org