Re: what advantage for using MTS

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:<3b4d57d3$1_at_news.iprimus.com.au>...
> Think of it this way.
>
> I fire up SQL Plus. I thereby obtain a dedicated server process, together
> with a private bit of memory space (the PGA). I then go for a smoke break.
> Oh, then I go for lunch, take in a bit of shopping, have a snooze on a park
> bench, and eventually come back to the office for a bit of a natter with the
> office floozies. Finally, about 4 hours later, I issue my long-awaited SQL
> command (inevitably, 'select * from emp') and do some real work on the
> server.
>
> For X hours, my server process has been sitting doing squat diddly, and
> chewing up CPU cycles and (more importantly) swathes of scarce memory to
> boot.
>
> That's exactly what MTS is designed to avoid (if *I* don't stress a shared
> server process, someone else likely will). Wasted resources.
>
> It's also probably the only way you'll get hundreds of concurrent users
> connected to your server, unless you have shares in a Taiwanese silicon
> foundry.
>
> I've actually swung in my opinions in the past few months. I've come to the
> conclusion that you need a really good reason *Not* to be running MTS, given
> that even under an MTS setup, DBAs and people with heavy needs can acquire a
> dedicated server connnection when they need to.
>
> Regards
> HJR
>
>

Howard, it used to be that if a session issued a wait for an alert (dbms_alert) that it would cause queueing for all the session assigned to the same MTS server so if your application made use of alerts you needed to avoid using MTS or assign the alert waiters to a dedicated session which may or may not be an easy thing to do. Question: Do you know if this is still true?

• Mark D Powell --