Results 1 to 7 of 7
  1. #1
    Join Date
    Oct 2002
    Location
    Toronto, Canada
    Posts
    12

    Unanswered: retry sql after a dealock ....

    I am having a problem finding a way to retry a sql after a deadlock (or any other error for that matter)....

    my current approach has been to put a 'try' block in a while loop and setting a variable in the 'catch' to detect the error... it does not seem to work...

    I am looking for a sample code to do this

    Thanks,
    Paul
    Paul
    www.dbmsguy.com

  2. #2
    Join Date
    Oct 2002
    Location
    PRC Beijing
    Posts
    10

    Re: retry sql after a dealock ....

    String temp1 = "test1";

    try {
    if (temp1.equalsIgnoreCase("test1")) {
    throw new Exception("aaaa");
    }

    } catch (Exception e) {
    System.out.println("aaaa");
    }

  3. #3
    Join Date
    Oct 2002
    Location
    Toronto, Canada
    Posts
    12

    Angry

    the problem is not actually catching the exception, the problem is doing anything with it...

    so what is happening, is :

    try{
    exec my sql
    } catch (SQLExecption e) {
    check the error for -911
    }

    this was all in a while loop...

    the PROBLEM is that I am executing all of this based on a cursor and the cursor seems to get messed up once the -911 occurs, so the sql gets re-executed, but when I go back for an rs.next() the cursor is gone or messed up or whatever.
    Paul
    www.dbmsguy.com

  4. #4
    Join Date
    Oct 2002
    Location
    PRC Beijing
    Posts
    10
    Hi,

    I am not very clear about your sql, but i think when your sql run exception, you should resign a value to your statment or recordset.

    Maybe your upper class should catch this exception?

    Best Regs

  5. #5
    Join Date
    Nov 2002
    Posts
    9

    2 connections

    As a Hack, I would create 2 Connection objects and put your outer ResultSet on one and your inner ResultSet on another. See if this eliminates the problem.
    Actually, now that I think about it, it probably will since I think a deadlock is going to force the transaction to rollback and if you're cursoring an outer recordset it will cause that cursor to implicitly close (I think).
    This may be your only solution... I would, however be pretty concerned that you have an app that you can easily deadlock.

  6. #6
    Join Date
    Oct 2002
    Location
    PRC Beijing
    Posts
    10

    I agree with u

    Hi,

    I think it is a good method. Although sometime we donot need to build up 2 connection 2 statment, 2 recordset.

  7. #7
    Join Date
    Oct 2002
    Location
    Toronto, Canada
    Posts
    12
    thank you...

    yes, my cursor gets closed which is the root of my problem... I will try what you are suggesting.
    Paul
    www.dbmsguy.com

Posting Permissions

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