Case Status is displayed as "Error: Exception". Why?
Hi All,
Case status for some child cases are displayed as "Error: Exception" in the Case Contents table. Assignments with errors for Worklist/ Work basket is having the following details for relevant cases.
"Problem trying to prepare SQL for lock insert "insert into WAM_DATA_DEV1.pr_sys_locks ( pxCreateDateTime, pxCreateOpName, pxCreateOperator, pxCreateSystemID, pxExpireDateTime, pxLockHandle, pxObjClass, pxOwnerId, pxSystemName, pxSystemNode, pxUpdateDateTime, pxUpdateOpName, pxUpdateOperator, pxUpdateSystemID, pxUserHost, pyLabel, pzInsKey) values (?, ?, ?, ?, ?, ?, 'System-Locks', ?, ?, ?, ?, ?, ?, ?, ?, '', ?)": code: 0 SQLState: Message: enlist: caught Exception"
How can we resolve this issue? We faced this issue in production env as well.
Accepted Solution
L Chase
GB
@Dhanusha, this appears to a DB deadlock situation. Could be transaction locks being requested in opposite or conflicting order. Each then ends up waiting on the other indefinitely. If you're using custom code for these transactions, check that the order of the locks should be exactly the same. If this is not using custom code, then check for a bug-fix on your version of Pega.
C3i
IN
Hi,
Looking at the issue from image I think you are having issue in inserting lock information to OOTB DB Table. Please check log error for more information on exception and check the db access for Pega Application.
Hope providing full log error might help people helping you. Try in PDN for any OOTB Issues based on version of Pega you are using and frameworks if had any.
Thanks,
Harsha A.
EvonSys Inc
US
Hello Harsha,
Thank you for the clarifictaion. We couldn't get the log file since issue was produced before some days, and we are keeping the log only few days. I am tryinng to reproduce this in Dev and check the assignment errors daily for get the similer error log from Dev.
Accepted Solution
L Chase
GB
@Dhanusha, this appears to a DB deadlock situation. Could be transaction locks being requested in opposite or conflicting order. Each then ends up waiting on the other indefinitely. If you're using custom code for these transactions, check that the order of the locks should be exactly the same. If this is not using custom code, then check for a bug-fix on your version of Pega.