Cursor for update get stuck while running the program

Question

Dear
i am using below mention program but work and get stuck. please any idea how can reslove this.
declare
l_segment1 VARCHAR (100);
CURSOR req_number_cur
IS
SELECT TO_CHAR (current_max_unique_identifier + 1)
FROM po_unique_identifier_control
WHERE table_name = 'PO_REQUISITION_HEADERS'
FOR UPDATE OF current_max_unique_identifier;
BEGIN
fnd_client_info.set_org_context (101);
mo_global.set_policy_context ('S', 101);
dbms_output.put_line('testing');
begin
OPEN req_number_cur;
FETCH req_number_cur
INTO l_segment1;
IF req_number_cur%NOTFOUND
THEN
--do something
NULL;
--insert statement
UPDATE po_unique_identifier_control
SET current_max_unique_identifier = current_max_unique_identifier + 1
WHERE CURRENT OF req_number_cur;
END IF;
CLOSE req_number_cur;
end;
END;
---thanks
appreciate you help.

Answer 1

Do you realise that this is a flawed approach?
Performance in a multi-user and multi-process database system is about the ability to do things simultaneously.
Simple analogy. You have a McDonalds. You have a 100 customers wanting to be serviced. What will be better? Having the customer all queuing in a single long queue to be serviced by a single cashier?
Or 10 cashiers, 10 queues, and the ability to service 10 customers at the same time?
It should be very obvious that the ability to service 10 customers at the same time is a lot better than only servicing a single customer at a time.
Likewise, Oracle can service 1000's of different sessions all inserting data.
Now you want to create a single queue for all insert transactions - and give each one a unique and sequential identifier. This will literally kill performance. It will turn a 32 CPU server into a 1 CPU desktop as all that extra CPU power can never be used as all the sessions need to get into a single queue and be serviced one at a time.
Also consider the functionality of your approach. Session 1 gets a 5 unique identifiers as it wants to insert 5 rows. Session 2 gets the next 3 sequence numbers. Session 1 aborts and rolls back its transaction (numerous practical reasons exist for why this can and do happen).
What is the status now in the database table? 5 numbers are now "missing".
So despite your severely flawed attempt to enforce serialisation and sequential numbering, it will fail. So why then even contemplate turning the Oracle database from being able to service multiple concurrent sessions at the same time, to a slow single-user/single-process database that can only service a single request at a time?
The CORRECT approach in Oracle is to use a sequence generator (see the CREATE SEQUENCE command in the <i>SQL Reference Guide</i>). Use it. Do not try a flawed approach that WILL fail and that WILL have a very severe performance impact.