IBM Support

IZ26477: LOCK/LATCH "DEADLOCKED" WITH EACH OTHER, CAUSED UDP CALL AND OLR WAITING FOR EACH OTHER

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Lock waiting and latch waiting caused "deadlock" inside DB2 so
    that a UDP call and OLR process may waiting for each other.
    
    from the stack, users should be able to see latch waiting /
    holding information
    
    <LatchInformation>
    
    Waiting on latch type:
    (SQLO_LT_sqlrlc_anchor_common__anchor_latch) - Address:
    (0x260ab93a4), Line: 71, File:
    /net2/d_v9_bld4/v9_bld4/db2_v91fp3/linuxamd64nocc/special_18159/
    engn/include/sqlrlc_inlines.h
    
    </LatchInformation>
    
    <LatchInformation>
    Holding Latch type: (SQLO_LT_sqlrlc_anchor_common__anchor_latch)
    - Address: (0x260ab93a4), Line: 71, File:
    /net2/d_v9_bld4/v9_bld4/db2_v91fp3/linuxamd64nocc/special_18159/
    engn/include/sqlrlc_inlines.h
    Holding Latch type: (SQLO_LT_sqlrlc_anchor_common__lru_latch) -
    Address: (0x260ab93a8), Line: 239, File: sqlrlc_flush.C
    </LatchInformation>
    
    When this problem happened, EDU A is waiting for latch that held
    by EDU B, but EDU B is waiting for lock held on EDU A:
    
    Lock timeout (seconds)                     = -1
    Locks held by application                  = 9
    Lock waits since connect                   = 232198883
    Time application waited on locks (ms)      = 165973133 <-------
    keep waiting for locks
    Deadlocks detected                         = 1
    Lock escalations                           = 0
    Exclusive lock escalations                 = 0
    Number of Lock Timeouts since connected    = 0
    Total time UOW waited on locks (ms)        = 0
    

Local fix

Problem summary

  • User Affected: ALL
    Problem Description:LOCK/LATCH "DEADLOCKED" WITH EACH OTHER,
    CAUSED UDP CALL AND WAIT FOR EACH OTHER
    Problem Summary:
    Lock waiting and latch waiting caused "deadlock" inside DB2 so
    that a UDP call and OLR process may waiting for each other.
    
    from the stack, users should be able to see latch waiting /
    holding information
    
    <LatchInformation>
    
    Waiting on latch type:
    (SQLO_LT_sqlrlc_anchor_common__anchor_latch) - Address:
    (0x260ab93a4), Line: 71, File:
    /net2/d_v9_bld4/v9_bld4/db2_v91fp3/linuxamd64nocc/special_18159/
    engn/include/sqlrlc_inlines.h
    
    </LatchInformation>
    
    <LatchInformation>
    Holding Latch type: (SQLO_LT_sqlrlc_anchor_common__anchor_latch)
    - Address: (0x260ab93a4), Line: 71, File:
    /net2/d_v9_bld4/v9_bld4/db2_v91fp3/linuxamd64nocc/special_18159/
    engn/include/sqlrlc_inlines.h
    Holding Latch type: (SQLO_LT_sqlrlc_anchor_common__lru_latch) -
    Address: (0x260ab93a8), Line: 239, File: sqlrlc_flush.C
    </LatchInformation>
    
    When this problem happened, EDU A is waiting for latch that held
    by EDU B, but EDU B is waiting for lock held on EDU A:
    
    Lock timeout (seconds)                     = -1
    Locks held by application                  = 9
    Lock waits since connect                   = 232198883
    Time application waited on locks (ms)      = 165973133 <-------
    keep waiting for locks
    Deadlocks detected                         = 1
    Lock escalations                           = 0
    Exclusive lock escalations                 = 0
    Number of Lock Timeouts since connected    = 0
    Total time UOW waited on locks (ms)        = 0
    

Problem conclusion

  • Problem was first fixed in Version 9.1 Fix Pack 6
    

Temporary fix

Comments

APAR Information

  • APAR number

    IZ26477

  • Reported component name

    DB2 DPF

  • Reported component ID

    5724N7400

  • Reported release

    910

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2008-07-07

  • Closed date

    2008-10-23

  • Last modified date

    2008-10-23

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    IZ26478

Fix information

  • Fixed component name

    DB2 DPF

  • Fixed component ID

    5724N7400

Applicable component levels

  • R910 PSY

       UP

[{"Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"DB2 for Linux- UNIX and Windows"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"910"}]

Document Information

Modified date:
03 October 2021