Internals of querying the concurrent requests' queue - revisited for R12.2

• I used the VM templates provided by Oracle to build my R12.2.4 test environment. By the way, I didn't expect that the process of getting the environment up would be so simple! Downloading the media files from edelivery.oracle.com was the most time-consuming step, once done - it took me just 1 hour to un-compress everything, import the Virtual Assembly file and bring up the R12.2.4 environment on my laptop.
• 3 Standard managers are defined by default
• Sleep seconds were left as is = 30 seconds
• Cache size was increased from 1 to 5.
• Identified the 3 DB processes that belong to the Standard managers:

  select sid, serial# from v$session where module='e:FND:cp:STANDARD'

• I enabled tracing with binds and waits for each of them like this:

  exec dbms_monitor.session_trace_enable(sid,serial#,true,true);

• Once that was done I submitted one concurrent program - "Active users" and waited for it to complete.
• I disabled the tracing and collected the trace files.

  exec dbms_monitor.session_trace_disable(sid,serial#);

• Collected the trace files

Before the "Active Users" Request Was Submitted

• All manager's processes still compete for the same requests. If the query is executed at the same time, the same list of concurrent requests will be retrieved by all processes.
• The constants literals used in lines 30-32 mean that the query for checking the queue is still built when the concurrent manager process starts up. These constants are mainly used to implement the specializations rules in the query.
• Only rowid for the pending requests' rows in FND_CONCURRENT_REQUESTS are fetched.
• The sleep time is clearly visible on lines 41,42 and 48,49

After the "Active Users" Request Was Submitted - Starting the Concurrent Request

Conclusions

• The coordination between manager processes is still not happening to distribute the requests, but the managers all query the queue the same way and then compete between themselves to lock the requests' entries on the table 1st. The process that gets the lock also gets to execute the concurrent request.
• The cache size variable couldn't be observed in the trace files, but as far as I remember from my previous research the process would only fetch "cache size"-number of rowids using the 1st query in this post. This could be tested by submitting larger volume of requests simultaneously.
• The "sleep seconds" kicks in only when the manager process didn't fetch any rowids from the queue. After all the cached requests are attempted/executed by the manager process, the queue is checked again immediately without waiting for the "sleep seconds" (Not explained in detail in this post, but it's revealed in the trace files)
• The DMLs used to query the FND_CONCURRENT_REQUESTS and to lock the row are very very similar to Pre-R12.2 releases of e-Business Suite (Another sign that the process hasn't changed, though one change that I see is the addition of where clause predicates for Checking the Editions).