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

Billy wrote:
> Joe Weinstein wrote:
>

>>Hi. I have an application which makes several (10-50)
>>separate JDBC connections to an Oracle DBMS, and uses
>>these connections indefinitely. Can you tell me any
>>reason I would prefer or care about whether the DBMS
>>is configured sa MTS or not?

[...]
>
> I will especially insist on using MTS for JDBC connections - assuming
> this is from an app server. I have lost count of the number of times
> app servers fail to close connections when done (guess this can be
> called pooled connection leaking on the app server side).

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

[...]
>
> With Dedicated Server (specifically talking Unix here), every server
> process is a Unix process. It takes up kernel resources and memory
> resources. There are ulimits and kernel limits and most of all, memory
> utilisation, to consider. Dedicated Server does not scale. MTS does. A
> statement of fact and not opinion.
>

This is the exact same argument you use for claiming that one should never ever run more than one Oracle instance on a machine. Following this logic, you must be running all your Unix boxes in single user mode, since obviously multi-user mode leads to inefficient use of memory and kernel resources and is not scalable. 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.

> Now, do you only start to consider using MTS for scalability when
> dealing with more than a 1000 connection? Or do you design and
> configure FROM THE START for a system to be scalable?

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 (I suspect this suggestion will be lost on you, since in your world you appear to always and everywhere have a 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.

-Mark Bole Received on Wed Sep 14 2005 - 11:00:47 CDT