What are Concurrent Managers and Concurrent Processing?

---

Concurrent Managers, typically, allow you to execute long running and data intensive application programs asynchronously. They are one of the core components of the Oracle E-Business Suite, the bane of many Apps Administrators lives, and the workhorse of the application. Before we get too far into the discussion of Concurrent Processing, though, it is important that we have a basic understanding of the vocabulary and the ideas involved.

Concurrent Manager

A Concurrent Manager is a special Concurrent Program that works as a mechanism for starting and running Concurrent Programs that operates during the times and days that are predefined as its work shift. These managers can run any kind of Concurrent Program including OS programs, C programs, reports, Java programs, and PL/SQL programs.

Concurrent Program

A Concurrent Program runs at the same time that other programs are allowed to run; it runs as a background process while OLTP continues to occur on the system and (usually) while other Concurrent Programs are allowed to run.

When a requested Concurrent Program that is available to run is based on when it was scheduled to start (a parameter specified by the user requesting it), its priority (a higher priority program can cause a lower priority program to wait temporarily for run resources), and its compatibility with other currently running programs (some programs are defined as incompatible with certain other Concurrent Programs).

Concurrent Programs are defined to the system using the Define Concurrent Program screen. If there were parameters defined by the programmer, they are also defined through this screen. Different programs take different parameters in different ways. A SQL*Plus or a host script program accept positional parameters and must be specified in the Concurrent Program Details zone of the Define Concurrent Reports form in exactly the same sequence that the program expects them. An Oracle Reports concurrent report takes keyword parameters. The token name that the programmer gave the report when he wrote it has to be the parameter name that you register the report. A SQL*Loader Concurrent Program requires that all of its parameters be passed in as a continuous string. This string is defined in the Execution Options field of the Concurrent Program zone. When defining a concurrent SQL*Loader job, you do not use the Details zone.

The parameters that you put into the Details zone are carried in the application as a special Descriptive Flex field.

Concurrent Process

A Concurrent Process is an instance of a currently running Concurrent Program or other concurrent request. Every time a Concurrent Manager goes out to the FND_CONCURRENT_REQUESTS table and there is a request waiting and available to run and the Concurrent Manager starts running it, that running job is considered a Concurrent Process.

Concurrent Request

A concurrent request is a request for a Concurrent Manager to run a Concurrent Program as a Concurrent Process. A user makes a concurrent request anytime she goes out and requests an immediate or future scheduled job to be run as a concurrent job. To schedule a concurrent request to run at some point in time in the future, you specify, at request time, the starting date and time that you want the request to be started, the time of day and frequency of resubmission, if this is going to be a recurring job, and the stop date and time, if any, at which point you want the job to no longer be run.

Request Group

A request group is a set of reports or other Concurrent Programs that have been defined by the sysadmin to assist in control of user access to these reports and programs. They can be used to control access in two ways. Access can be granted or denied according to the users' responsibility (e.g., receivables manager). The other way that users access a request group would be through a customized Submit Request form. This is a relatively simple and Oracle supported customization with detailed instructions in the Oracle Applications System Administrator's Guide that entails registering a form function and passing in arguments to the Submit Request form. Only a user with sysadmin authority has the ability to create a request group.

Request Set

A request set sets the run options, print options, and (if applicable) any parameter values for a collection of reports or programs not already included in a request group. End users can define these and own the request sets that they create. These sets are connected to the user's sign-on ID and are available to that user regardless of which responsibility that user is currently logged into.

Concurrent Manager

Every time a request is made for a Concurrent Program, an entry gets put into the FND_CONCURRENT_REQUESTS table along with its unique request ID. From this table, the Concurrent Manager retrieves requests based on their availability to run.

Work Shifts

Work shifts for a Concurrent Manager is similar to a work shift for a human being. It is defined as those hours for which a Concurrent Manager is defined for working. Work shifts are defined using the Work Shift form. Often additional managers are defined to work off hours when large batch jobs are scheduled to not adversely impact the performance of the OLTP that occurs during a person's work shift.

Concurrent Request Cache

Another component of the Concurrent Processing environment is the Concurrent Request Cache or the Concurrent Request Buffer. The Concurrent Request Cache gets set when each manager is defined and it specifies the number of requests each Concurrent Manager process can hold in its memory each time it reads from the request queue (FND_CONCURRENT_REQUESTS). Its main purpose in life is to reduce the number of cycles each manager has to make to the concurrent request table and as a result lessens the likelihood of locked rows on the FND_CONCURRENT_REQUESTS table or the likelihood of more than one manager attempting to start a concurrent request at the same time. Blank or zero value cache sizes are automatically assigned a value of 1 when they are started. If you find that, in your environment, you reprioritize requests frequently, leave the cache size at the default setting of 1 so that reprioritizations can be picked up as soon as they happen and the requests run accordingly. If you rarely reprioritize requests and have managers that service many short running requests, you can safely set the cache size to twice the target processes, thereby increasing the throughput of the Concurrent Managers by limiting their attempts at sleep time.

---