Re: pros/cons of dedicated vs. MTS connections?

From: Mark Bole <makbo_at_pacbell.net>
Date: Fri, 16 Sep 2005 00:39:52 GMT
Message-ID: <svoWe.1236$2J3.266@newssvr21.news.prodigy.com>

Billy wrote:

> Mark Bole wrote:
>

>>That's the whole point of a JDBC connection pool -- you never close the
>>connection.

>
> You're missing the fact that I was talking about JDBC connection pool
> leaking. I.e. the connection pool continues to grow, with original
> pooled connections not being used (and the socket handle still open).
> This means that the number of sessions on the Oracle side keeps on
> increasing.

In the Weblogic product, at least, there are settings for limiting the max number of connections in the pool. Every time reaching the max became a problem, in my experience, it was a bug in the application code that needed to be fixed regardless of connection pool issues.

[...]
>

>>And you must always ride on a bus
>>or train, since a passenger car or bicycle does not scale very well
>>either.   And then there's your cozy dormitory bed, since a personal
>>bedroom does not scale very well.

>
>
> Poor analogy. If you are in the housing or transport business, do you
> want a 100 bicycles, a 100 personal bedrooms, or rather 10 double
> decker busses and 10 dorms, for dealing with your business?
>

And, if I am not in the housing or transport business...?

>>If you have a scalabity problem, then by all means use shared server
>>(it's not called MTS anymore since it never was multi-threaded) to
>>address it.  If you don't have a scalability problem, then don't worry
>>about it

>
>
> Scalability is only a problem when you don't design and configure for
> it.

And, when you actually have a scalability problem.

> Yes.. that must be why the SELECT COUNT on a fact table in a warehouse
> instance of mine takes 30 fricken seconds to run, before it gives an
> answer of 800+ million rows. That is a real scalability problem on that
> fact table.. Of course, the so-called experts here will design it
> differently enable that SELECT COUNT to run in 10 seconds instead?

Bravo. Sounds like you have done a good job of addressing your scalability problem.

>>And since you can use either or both at the same time, there is no cost
>>to starting one way and then changing later if it makes sense.

>
>
> If ABC is done at the start to ensure scalability, then you're not
> going to run into a brick wall at a later stage and then have to
> scramble to get it ABC implemented.

There is no brick wall. Shared server and dedicated server can co-exist, you can switch back and forth at will.

> Scalability is not something that you think of throwing in at a later
> stage ro prevent the crap from hitting the fan. You design with
> scalability as core criteria from the start.
>
> Okay, maybe not you. At least that I what I (try) to do...
>

Valid, if you anticipate a scalability problem. On the other hand, I know of real-life situations where vast sums were expended in years past to address anticipated scalability problems that in fact never materialized.

> --
> Billy
>

-Mark Bole Received on Thu Sep 15 2005 - 19:39:52 CDT