Time Slicing deadlocks on multiple tables on PostgreSQL (GCP)

book

Article ID: 221066

calendar_today

Updated On:

Products

Clarity PPM SaaS Clarity PPM On Premise STARTER PACK-CLARITY PPM

Issue/Introduction

We are seeing Time Slicing failing with deadlocks repeatedly.

STEPS TO REPRODUCE:

  1. Set up an live environment with concurrent updates in MUX on Clarity and SQL Curves enabled
  2. Schedule Time Slicing job to run as default, every 1 min

Expected Results: The job to run as expected

Actual Results: Timeslicing repeatedly fails with deadlocks (could be up to 10-20 times per day)

NOTE: fin_cost_plan_details deadlocks are NOT INCLUDED in this defect, and instead addressed by defects DE61974, DE60813

ERROR 2021-07-27 11:16:50,543 [Dispatch Time Slicing : [email protected](tenant=clarity)] niku.blobcrack (clarity:admin:22542126__382C3001-AE60-4E08-8A3D-A80E179D253E:Time Slicing) Exception during blobcrack process
com.niku.union.persistence.PersistenceDeadlockException: 
SQL error code: 0
Error message: ERROR: deadlock detected
  Detail: Process 24368 waits for ShareLock on transaction 4050256554; blocked by process 20060.
Process 20060 waits for ShareLock on transaction 4050256592; blocked by process 24368.
  Hint: See server log for query details.
  Where: while locking tuple (22095,8) in relation "prj_baseline_details"
Executed:
 UPDATE PRJ_BASELINE_DETAILS
              SET SLICE_STATUS = 1
              WHERE BASELINE_ID IN
              (
                 SELECT B.ID
                 FROM PRJ_BASELINES B
                 WHERE B.SLICE_STATUS = 2
              ) 

 

Environment

Release : 15.9.2

Component : CA PPM TIME SLICING

Resolution

Workaround: None, ignore the deadlock and the record will usually be picked up on next run

This is DE62122, in review by Engineering