Tracing, debugging and fixing Row Lock Contentions

Off late, I've been facing a lot of row lock contentions. The table in contention seems to be a particular table. This is generally what happens - - Developer 1 starts a transaction from Oracle Forms front end screen - Developer 2 starts another transaction, from a different session using the same screen ~5 minutes in, the front end seems unresponsive. Checking sessions shows row lock contention. The "solution" that everyone throws around is to kill sessions :/ As a database developer - What can be done to eliminate row lock contentions? - Would it be possible to find out which line of a stored procedure is causing these row lock contentions - What would be the general guideline to reduce/avoid/eliminate such problems which coding? If this question feels too open-ended/insufficient information please feel free to edit/let me know - I'll do my best to add in some additional information. ----- The table in question is under a lot of inserts and updates, I'd say it's one of the most busiest tables. The SP is fairly complex - to simplify - it fetches data from various tables, populates it into work tables, a lot of arithmetic operations occur on the work table and the result of the work table is inserted/updated into the table in question. ---- The database version is Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit. The flow of logic is executed the same order in both the sessions, the transaction isn't kept open for too long ( or at least I *think* so), and the locks occur during active execution of transactions. ----- **Update:** The table row count is larger than I expected, at about 3.1 million rows. Also, after tracing a session I found that couple of update statements to this table are not utilizing the index. Why is it so - I'm not sure. The column referenced in the where clause is indexed. I'm currently rebuilding the index.