Deadlock - Seect for Update with order by

Printable View

06-10-2011, 04:56 AM
sumit

Deadlock - Seect for Update with order by

I am using a "select for update" with order by clause which is getting a deadlock. I was expecting that adding an order by should never lead to a deadlock, assuming the rows selected FOR UPDATE are locked in the order as
they are returned.

But is that true? Are the rows selected FOR UPDATE locked in the same
order as they are returned (as specified in ORDER BY)? If yes, why am I getting a deadlock?

P.S: transactions are getting committed by each session after 100 records (1 commit on each 100 records).

Regards
Sumit
06-11-2011, 04:51 PM
PAVB

Quote:

Originally Posted by sumit

I am using a "select for update" with order by clause which is getting a deadlock. I was expecting that adding an order by should never lead to a deadlock, assuming the rows selected FOR UPDATE are locked in the order as
they are returned.

But is that true? Are the rows selected FOR UPDATE locked in the same
order as they are returned (as specified in ORDER BY)? If yes, why am I getting a deadlock?

P.S: transactions are getting committed by each session after 100 records (1 commit on each 100 records).

Is "select for update" populating a cursor?

In the affirmative case, since locks are held for the duration of the transaction, when using an explicit cursor and "for update" option you should not commit across fecthes.
06-16-2011, 12:28 AM
sumit

"you should not commit across fecthes" - can you explain more on this please?

as I said earlier, I am runing this application in 10 parallel thread reading 10 separate input files. After each 100 records, the process will commit records in the database. Are you seeing anything wrong doing this?

Regards
06-16-2011, 08:08 AM
PAVB

Quote:

Originally Posted by sumit

"you should not commit across fecthes" - can you explain more on this please?

If you populate a cursor with let's say 100,000 rows then loop the cursor and commit every let's say 1,000 rows you are committing across fetches.

Quote:

Originally Posted by sumit

...as I said earlier, I am runing this application in 10 parallel thread reading 10 separate input files. After each 100 records, the process will commit records in the database. Are you seeing anything wrong doing this?

Yes.
100 rows? Why not 1,000? or 10,000?
Most probably you are commiting too often.