Re: 2nd Listener
Date: Mon, 29 Mar 2010 18:45:31 +0200
Message-ID: <81c3pfFuanU1_at_mid.individual.net>
On 29.03.2010 17:40, Bill wrote:
> We have internal users connecting via Forms and external users
> connecting via Oracle Apps Server 10.1.
>
> Currently, there's one listener for everything.
>
> Would there be any merit in creating a second listener for just the
> external users?
I cannot see any but others might. IMHO a second listener only helps with robustness (if one listener fails you can use the other one). OTOH I cannot remember having heard of dying listeners and if it is on the same machine as the DB chances are that if the listener is unavailable the DB is as well.
> The connection pooling is done via application server, so I see no
> point in creating a shared server arrangement.
Absolutely agree. Especially since shared servers can create subtle deadlocks if you run out of server processes (Tom Kyte describes this in "Effective Oracle by Design"). Basically your connection pool in the app server takes on the task of distributing work across several server processes. You should only make sure your pools are properly sized.
> I'd like to keep a large amount of Oracle processes open in the
> database for the large influx of online users we're expecting so if
> anyone knows a good way on the apps server for me to do that I'd be
> most grateful. I know there are a few parameters like MaxClients but
> it would be nice to hit the right ones as the time we have for testing
> isn't that much.
This question is extremely JEE container specific so you'll find better answers in a forum suited to the app server you are using. My general 0.02EUR on this is: just set min size to max size and don't use all those fancy "we clean the pool in the background and fill it for you" features.
Kind regards
robert
-- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/Received on Mon Mar 29 2010 - 11:45:31 CDT