What are Concurrent Managers

Concurrent processing is one of the key elements of any E-Business Suite system

• Concurrent Managers are the controllers of background processing for Oracle Applications.
• The main function of Concurrent Managers is to regulate, and control process requests based upon a set of rules.
• It is a technique used to execute noninteractive, data-dependent programs simultaneously in the background.
• Oracle Applications comes with predefined managers, including the Internal Concurrent Manager (ICM), Standard Manager, Conflict Resolution Manager (CRM) and Transaction Managers (TM).
• The Internal Concurrent Manager controls all the other Concurrent Managers that are operating system processes that poll for requests.
• Within Applications, you can also create any number of Concurrent Managers to handle particular types of requests or programs and specialize them for your business requirement
• The ICM (Internal Concurrent Manager) controls all of the other concurrent managers.
• The Standard Manager accepts any and all requests. It has no predefined specialization rules and is active all the time. It is not recommended to add specialization rules to the standard manager as it is common to cause problems.
• The Conflict Resolution Manager resolves conflicts, such as request incompatibilities.

It provides scheduling and queuing functionality for background jobs, and it’s used by most of the application modules. As many things depend on concurrent processing, it’s important to make sure that the configuration is tuned for your requirements and hardware specification.

how does a concurrent manager process work? Here is a diagram I created to explain it:

Reference - 

Concurrent manager reference (pythianblog.wpengine.com)

Internal workflow of a concurrent manager process

Diagram to provide more details about them:

1. This is where the story begins. There is no EXIT state in the diagram as the managers normally process requests in an infinite loop. Obviously, there is a way for a concurrent manager process to receive the command to quit when the managers need to be shut down, but that’s not included here for simplicity.

2. Internal Concurrent Manager (ICM) requests the Service Manager (FNDSM) to start up the Concurrent Manager process. For the Standard Manager processes, the binary executable FNDLIBR is started. For the Inventory Manager, it’s  INVLIBR. There are others too.

3. The manager process connects to the database and reads the settings (e.g profile options, sleep seconds, cache size).

4. The process saves information about itself in FND_CONCURRENT_PROCESSES table (os process id, database name, instance name, DB session identifiers, logfile path and name, and others). It also updates FND_CONCURRENT_QUEUES by increasing the value of RUNNING_PROCESSES.

5. The concurrent manager process collects information from the database to build the SQL for querying the FND_CONCURRENT_REQUESTS table. The query will be used every time the manager process looks for scheduled concurrent requests.  This is the only time the manager process reads the Specialization Rules (which programs it is allowed to execute) from the database. Keep in mind that if the specialization rules are changed while the managers are running, they are bounced without warning as that is the only way to update the specialization rules cached by the manager process.

6. The SQL (from step 4) is executed to collect information about pending concurrent requests from FND_CONCURRENT_REQUESTS table.

7. The results are checked to verify if any requests are pending for execution.

8. If no requests are pending for execution, the manager process sleeps and then goes to step 5. The “Sleep Seconds” parameter of the  “Work Shifts” settings of the concurrent manager determines how long the process sleeps before FND_CONCURRENT_REQUESTS table is queried again. This is the only time the “sleep seconds” setting is used.

9. If there is at least one concurrent request pending for execution, the concurrent manager process caches rowids for the FND_CONCURRENT_REQUESTS rows of pending concurrent requests. The “Cache Size” setting of the concurrent manager specifies how many rowids to cache.

10.    The cached list of rowids is checked to verify if there are any unprocessed concurrent requests (rows in FND_CONCURRENT_REQUESTS table) left. If none are left – the processing returns to step 5 and the FND_CONCURRENT_REQUESTS table is queried again.

11.    The next unprocessed rowid is picked from the process cache, and the processing starts.

12.    Concurrent manager process executes a SELECT-for-UPDATE statement to lock the STATUS_CODE in FND_CONCURRENT_PROCESSES for the request it’s about to process. This is the mechanism to ensure that each concurrent request is executed only once and only by one manager process even if many processes are running simultaneously. The SELECT-for-UPDATE statement can complete with “ORA-00054: resource busy and acquire with NOWAIT specified” or “0 rows updated” if another manager process has started processing the request already.

13. If the STATUS_CODE of the request was locked successfully, the concurrent manager executes the concurrent request. The processing moves to step 9 where the cached list of concurrent requests (rowids) is being checked again.

The workflow is not very complex, but it’s important to remember that there are normally multiple concurrent manager processes running  at the same time, and they are competing for the requests to run. This competition introduces another dimension of tuning for  settings, like number of concurrent manager processes, sleep seconds, or cache size.