How to avoid deadlock when multithreading updates one table same time?

Question

Multithreading calls the stored procedure at the same time to update data in one table. For a instance,
Table1
Col1 Col2 Col3
C1 1 1
C1 2 2
C1 3 3
C2 1 1
Table2
Col1 Col2 Col3
C1 1 10
C1 2 4
C1 3 3
C2 1 1
There are several steps I want:
1. Get the data in Table1 where Col1 = C1 in a cursor which has Col1 column and Col2 column.
2. Cycle them one by one, and get the Col3 data from Table2 where Col1 = C1 and Table2.Col2 = Table1.Col2. (Due to deadlock is my concern, we use temp table, definityly it is not a good way. :( )
3. Update Table1 Set Col3 = Table2.Col3.
My new idea is when I get the collection from Table1 which Col1 = C1, I use this way below.
First I set transaction in below way.
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
Then
select * from Table1 where Col1 = C1 for update nowait;
In my opinion, if one thread lock the data for update, other thread won't select out that locked data. Does it work?
Thank you.
Best regards,
Andreas

Answer 1

Why is the data submitted as a collection in the first place?
A collection is great as a program data structure - dealing with program variables. It is a very poor choice to use it to deal with Oracle data in a CRUD fashion.
The purpose, ito dealing with Oracle data, of a PL/SQL collection is for one thing and one thing only - context switching.
To reduce the number of times you need to step out of PL/SQL and into the SQL engine in order to pass data from one to the other. A collection allows you a bigger buffer area and thus less context switches.
And that's it.
A client (Java, C#, etc) that submits data to Oracle to be CRUD via a collection is a design flaw. A collection resides in "expensive" dedicated, non-sharable and non-scalable server memory.
In order to CRUD a collection, you either need to write bare bones feature methods yourself, or cast that collection into a SQL structure and use more powerful and flexible and feature rich SQL against it.
Which then begs the question - why did the client not submit that data directly to the SQL engine, either into a permanent table or a temporary table?
Performance and scalability are issues that need to be addressed at core design level. It is not something that can be tacked on and "fixed" after the fact. So you need to make very sure that your reasons for not wanting to use a temp table (for example), are valid and sound technical reasons.