Title: RE: Concurrent Manager
But every time I open an ITar, Support freaks because we have ours configured with the managers on the middle tier (Windows might be the issue, but that isn't usually when they balk) and not on the database tier...
and if you do a 2 tier install (at least
You are absolutely correct for Apps 11.0.x and before. And I'm not saying
that some performance is not lost due to network latency for some ConcMgr
programs.
But it ain't as bad as it used to be, because of the steady migration away
from chatty PRO*C and Reports code to more network-friendly
I keep Concurrent Managers on the DB server because the managers fire off
child processes
to run all requests and I do not want report jobs submitted by users that
are actually large batch-jobs
running over SQLNet. It would be the old Client-Server issue where
Reports on a Client ran
slower
Hemant,
That configuration was usual for Apps 11.0.x and prior, but with 11i it is
strongly recommended to take the default configuration and leave the ConcMgr
on the apps-tier instread of the db-tier.
Two major reasons:
* The gains in manageability (especially upgrades) far outweigh the
Not sure why you would necessarily want the reports server on the
database tier... Concurrent managers wake up periodically (like 60 or 90
seconds), query their tables to see if there are any jobs to run... run them if
there are and then go back to sleep. If they are all on the same tier,
Thanks April,
