Expand all | Collapse all

Deadlock Management Issues

  • 1.  Deadlock Management Issues

    Posted 06-06-2014 11:30 AM

    Hello all,

      We've implemented following within an ADS dialog to manage index deadlock situations where updates are occurring on a particular record type (PT-PK-SGNOUT-REC) owned by 5 system owned indexes (don't ask)


     ACCEPT DB-KEY INTO PT-WK-D431-DBKEY                    
                        FROM PT-PK-SGNOUT-REC CURRENCY.     
     IF DB-DEADLOCK                                         
         SNAP RECORD (PT-PK-SGNOUT-REC)                     
              TITLE 'PTELD431 - DEADLOCK MESSAGE'.          
         COMMIT ALL.                                        
         MODIFY PT-PK-SGNOUT-REC.                           

    The SNAP message is going to the log but the second MODIFY also seems to succumb to an '0829' error (and abort)

    Should I:

     - delay the second MODIFY in order to give more time to the competing transaction to complete

    - make repeated attempts (for a fixed number of times)

    - is the 'COMMIT ALL' insufficient in releasing enought of the resources to allow the competing transaction to complete



  • 2.  RE: [Application Developer Issues] Deadlock Management Issues

    Posted 06-06-2014 01:05 PM
    to be migrated

  • 3.  RE: [Application Developer Issues] Deadlock Management Issues

    Posted 06-06-2014 03:45 PM

    From perusing the journal recs (with jreport8), when 2 transactions deadlock, the process is successful.

    The failures are occurring when more than 2 trans are locked (as many as 7 a couple of days ago)

    At this stage, I'm thinking of adding code to re-attempt a few times (not sure how many but at least 6 or 7)

  • 4.  RE: Deadlock Management Issues

    Posted 06-07-2014 01:26 AM

    If the transaction also uses DC-Queue resources then you will want to use COMMIT TASK ALL - which I would try regardless - since some retrieval locks are left intact with only using COMMIT ALL - and this may be sufficient to cause the deadlocking?

    If that fails then introducing a WAIT and retry on the first nn29 may be useful - it has worked for us in the past.

    HTH - cheers - GaryC