dbms_alert Polling intervals - oracle

Question

Explain, please, here this paragraph from the documentation
WAITANY procedure. If you use the WAITANY procedure, and if a signalling session does a signal but does not commit within one second of the signal, a polling loop is required so that this uncommitted alert does not camouflage other alerts. The polling loop begins at a one second interval and exponentially backs off to 30-second intervals.
I correctly understand that here it is said that when WAITANY is called on the server, the thread queries the presence of events at certain intervals? And if I called WAITANY with a sufficiently long timeout, when an event occurs, will I be notified only after the current request interval expires? Those. on the server is about like this code
function WaitAny(ATimeout) {
const intervals = [0, 1, ....., 30);
for (i = 0; i < intervals.length; i++) {
Sleep(min(intervals[i], ATimeout))
if (IsExistsEvents())
return 0;
ATimeout -= intervals[i];
if (ATimeout <= 0)
return 1;
}
maxInterval = intervals[intervals.length - 1];
while (ATimeout > 0) {
Sleep(min(maxInterval, ATimeout))
if (IsExistsEvents())
return 0;
ATimeout -= maxInterval;
}
return 1;
}

Answer 1

No, it will still be "immediate".
When someones signals an alert, it will flick out a pipe message (a non-transactional blip) which the waiter will see. But of course, the waiter has not "officially" received the alert until the signaller commits.
So the waiter gets the blip, then waits on a lock (alerts are implemented with Oracle's standard locking mechanism). Because we're expecting the commit to come quickly.
If it doesn't, that's a problem because what if we get a signal from a different alert (because we are doing a WAITANY here). So when that commit does not come, we'll acquiesce and do the exponential backoff. But it is not "check for the alert at 1, 2, 4, etc seconds", it is "re-enter the wait for lock state every 1,2,4, ...seconds". So when that commit comes, we'll pretty much see it straightaway.
For example, I traced a 2 minute wait on an alert from someone who signaled but did not commit
declare
n varchar2(100);
m varchar2(100);
s int;
begin
dbms_alert.WAITANY(n,m,s);
end;
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 127.49 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.00 127.50 0 0 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 107
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
enq: UL - contention 9 32.01 127.47
log file sync 1 0.00 0.00
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
********************************************************************************
You can see the 2 minute wait was almost all on lock waits.