Nowait in a Loop

Question

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
SUBTYPE DOC_REC IS table_name_1%ROWTYPE;
    DOC_INFO    DOC_REC;
IF DOC_INFO.MANUAL_AUTO_IND = 'A'
THEN
     LOOP
         BEGIN
             SELECT *
                  INTO   DOC_INFO
                FROM   table_name_1
             WHERE  col_1      = IV_N_param1
                   AND  col_2 = IV_V_param2
            FOR UPDATE OF col_3 NOWAIT;
            EXIT;
          EXCEPTION
                WHEN LV_UPDATE_AND_LOCK THEN
                     NULL;
                WHEN OTHERS THEN
                      ERROR_MESG := SQLERRM||'Error While Selecting For Update';
                      RETURN (DOC_INFO);
          END;
      END LOOP;
END IF;
the above block will cause any problem.?
on my OLTP system, we are using advance queue feature,
Consider that two transaction ready to process from AQ, if first transaction puts lock in that above select and the second one will be in infinite loop because the same select will satisfy for second transaction, it is a issue we have identified and will have a control on it.
But first transaction itself it is holding lock, not released if we have kill the session and on from another schedule it is processing without cause any problem
Couldn't find the root cause of the slowness of first transaction. and we get this from AWR, the execution of above select was 4880986, 4211196

Answer 1

Do not understand the need for the loop. It will hit the same locked rows again and again, until these can be locked by it.
How is that better than using the select for update and have it waiting for these rows to be locked?
Beating the locked rows senseless in a tight loop is only consuming extra resources (cursor execution). It  is not going to make its locking of those rows happen any sooner.
The WHEN OTHERS exception handler is a serious bug in your code. An exception handler should never behave that way - suppress all errors and pretend that nothing is wrong, when that handler is not at the top of the call stack.