Results 1 to 2 of 2
  1. #1
    Join Date
    Jan 2003
    Posts
    2

    Question Unanswered: DEADLOCK_PRIORITY for Sybase ?

    Microsoft SQL Server has a veriable that can be used to help determine which of the two transactions will be the deadlock victim.

    Is there anyway in Sybase to specify which transcation will be the deadlock victim and which one won't ? Or . . . Is the transaction aborted merely always the one that has accumulated the least amount of CPU time for its session?

    I would have though that Sybase would be able to give its users some kind of way to prioritise what deadlock transactions will be aborted.

    Please see the text below which describes how MS SQL Server handles this.

    Any help is very much appreciated.

    Thanks



    -------------------------------------------------------------------
    Syntax
    SET DEADLOCK_PRIORITY { LOW | NORMAL | @deadlock_var }

    Arguments
    LOW

    Specifies that the current session is the preferred deadlock victim. The deadlock victim's transaction is automatically rolled back by Microsoft® SQL Server™, and the deadlock error message 1205 is returned to the client application.

    NORMAL

    Specifies that the session return to the default deadlock-handling method.

    @deadlock_var

    Is a character variable specifying the deadlock-handling method. @deadlock_var is 3 if LOW is specified, and 6 if NORMAL is specified.

    Remarks
    The setting of SET DEADLOCK_PRIORITY is set at execute or run time and not at parse time.
    ------------------------------------------------------------------------------



    PS. I have already tried to avoid the deadlocks with sproc, isolation levels of 0, etc... However, it would really be beneficial if I could prioritise which transaction will or will not be the deadlock victim.

  2. #2
    Join Date
    Jan 2003
    Posts
    62

    Re: DEADLOCK_PRIORITY for Sybase ?

    Answer is no.
    In Sybase ASE, the one with the less total CPU time will be selected as the victim (this is mentioned somewhere in the manual).
    There are, on certain situations, a process can be marked as the preferred victim, but this is all internal decision within ASE. In short, users have no means to specify such priority.


    Originally posted by BryanFuhre
    Microsoft SQL Server has a veriable that can be used to help determine which of the two transactions will be the deadlock victim.

    Is there anyway in Sybase to specify which transcation will be the deadlock victim and which one won't ? Or . . . Is the transaction aborted merely always the one that has accumulated the least amount of CPU time for its session?

    I would have though that Sybase would be able to give its users some kind of way to prioritise what deadlock transactions will be aborted.

    Please see the text below which describes how MS SQL Server handles this.

    Any help is very much appreciated.

    Thanks



    -------------------------------------------------------------------
    Syntax
    SET DEADLOCK_PRIORITY { LOW | NORMAL | @deadlock_var }

    Arguments
    LOW

    Specifies that the current session is the preferred deadlock victim. The deadlock victim's transaction is automatically rolled back by Microsoft® SQL Server™, and the deadlock error message 1205 is returned to the client application.

    NORMAL

    Specifies that the session return to the default deadlock-handling method.

    @deadlock_var

    Is a character variable specifying the deadlock-handling method. @deadlock_var is 3 if LOW is specified, and 6 if NORMAL is specified.

    Remarks
    The setting of SET DEADLOCK_PRIORITY is set at execute or run time and not at parse time.
    ------------------------------------------------------------------------------



    PS. I have already tried to avoid the deadlocks with sproc, isolation levels of 0, etc... However, it would really be beneficial if I could prioritise which transaction will or will not be the deadlock victim.

Posting Permissions

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