Immediate:
----------
If 'Locking Mode' is set to 'Immediate', the row is immediately locked upon modification. Locking occurs as soon as a key is pressed to enter or edit that value in the item. 'Immediate' is the default setting.

Quote:

Delayed:
--------
If 'Locking Mode' is set to 'Delayed', the row is not locked until
commit-time, specifically until changes are 'posted' to the database. Oracle Forms then compares the current value to the database value before issuing the UPDATE statement. The user will get an error if the row has been updated
since it was fetched.

I just want to pose some more questions which may lead you into the direction of a solution to your problem.

What I would like know, is:
Who is waiting on what? Did you try to trace the locking and / or locked sessions or query information about the sessions (from v$session_wait, v$session_event and v$system_event, v$open_cursor etc.)?
Did you try to google with search terms like "oracle session hang"?
Are there queries with a lot of union (all)'s ?
How do the application(s) connect to the database(s)(JDBC/OCI or TNS or else)?
Is dead session detection working correctly? Are there sessions which are suspisciously old and still open (except the background processes of course)? And do you know whether the client is still running or has logged off, has crashed or has been rebooted in the meantime? Then check our connection configuration. And do this "dead" sessions still own locks?
How do batch processes behave (if you have them)?
Are there a lot of long running operations?

More application oriented questions are:
Are we talking about client/server forms or web forms? Is the application closing its cursors efficiently when the forms call procedures?
Do the users open a lot of screens simultanously for example in query-mode and leave them inactive for a long time?
When does the application execute commits?
Hoe do users exit the application(s)? By switching of the client machines or with a decent logoff?