Deadlock - Seect for Update with order by
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 4 of 4

Thread: Deadlock - Seect for Update with order by

  1. #1
    Join Date
    Dec 2001
    Posts
    203

    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
    sumit

  2. #2
    Join Date
    Mar 2007
    Location
    Ft. Lauderdale, FL
    Posts
    3,554
    Quote Originally Posted by sumit View Post
    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.
    Pablo (Paul) Berzukov

    Author of Understanding Database Administration available at amazon and other bookstores.

    Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.

  3. #3
    Join Date
    Dec 2001
    Posts
    203
    "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
    sumit

  4. #4
    Join Date
    Mar 2007
    Location
    Ft. Lauderdale, FL
    Posts
    3,554
    Quote Originally Posted by sumit View Post
    "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 View Post
    ...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.
    Pablo (Paul) Berzukov

    Author of Understanding Database Administration available at amazon and other bookstores.

    Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width