Hi I'm doing some manually locking row in Oracle SQL for Oracle APEX, i use some AI to help with this but i have a feeling that I'm being bamboozle. I also read the docs and make a table to compare different kind of lock to be honest I don't really think i understand it. Here a table that i think each lock kind does:

Here is my SQL:
declare
l_old_sr_co_owner_list apex_t_number;
begin
-- row locking i'm assuming this is 'SS' lock
SELECT
srco.id__employee
BULK COLLECT
INTO l_old_sr_co_owner_list
FROM
my_schema.request req
LEFT JOIN my_schema.request__employee__sr_co_owner srco
ON req.id = srco.id__request
WHERE
req.id = :p18_id
FOR UPDATE;
-- doing modification on request and request__employee__sr_co_owner
end;
what i think this lock is doing:
- Don't allow update, delete to
request where id = :p18_id.
- Don't allow update, delete to
request__employee__sr_co_owner where id__request = :p18_id.
what i want additionally which this lock is not provide:
- Don't allow insert on
request__employee__sr_co_owner if id__request = :p18_id.
the AI is raising some issue that I not sure about:
If a request currently has zero co-owners, the LEFT JOIN evaluates to NULL for the child table, and locking behavior on those non-existent child rows can become unreliable or fail to prevent concurrent inserts into the child table. (This sound like non-sense to me but I'm not sure)
Bellow this code i also doing some prevent loss update so maybe locking request__employee__sr_co_owner is not necessary
-- prevent loss update
WITH sr_co_owner AS (
SELECT
id__request,
LISTAGG(id__employee, ':') WITHIN GROUP(
ORDER BY
id__employee ASC
) AS id__employee
FROM
my_schema.request__employee__sr_co_owner
GROUP BY
id__request
)
SELECT
CASE
WHEN utl_raw.compare(
standard_hash(req.sr_owner__employee
|| '-'
|| srco.id__employee, 'SHA256'),
hextoraw(:p18_hash)
) = 0 THEN
'0'
ELSE
'1'
END AS loss_update_status
INTO l_loss_update
FROM
my_schema.request req
LEFT JOIN sr_co_owner srco ON srco.id__request = req.id
WHERE
id = :p18_id;