I did delete the pzinskeys entries in pr_sys_locks table that showed up in the logs but not the entire table, but once i deleted all entries and the pool was empty, it still gets created with a new pzinskey and starts piling up. Did do a restart with marker clean up . Is full table truncate of pr_sys_locks necessary ?
[8/3/18 11:02:41:030 CEST] 00000017 SystemOut O 2018-08-03 11:02:41,030 [stenerThreadPool : 0] [ STANDARD] [Implementation:01.56] ( internal.services.ServiceAPI) ERROR JMS|ReceiveNotifications|ReceiveNotifications|ReceiveNotifications|A58F39374283FA0912BEE65EFED18B665 - JMS service [ReceiveNotifications][ReceiveNotifications][ReceiveNotifications] failed:Database-General A commit cannot be performed because a deferred save of instance XXX-DATA-COLOGGING-VVV EF1DD686-2FC1-4F47-98EF-D1C2763E200C failed :com.pega.pegarules.pub.database.DatabaseException: Database-General A commit cannot be performed because a deferred save of instance XXX-DATA-COLOGGING-VVV EF1DD686-2FC1-4F47-98EF-D1C2763E200C failed
Seems like it was a fix inside the activity referenced in the package. Once corrected, stopped listener, cleared any pending requestor in requestor pool, cleared queues of any poison messages and restarted listener and the problem didnt surface back.
Posted: 3 years ago
Posted: 6 Aug 2018 4:23 EDT
Simon Chan (chans3)
Principal GCS Solutions Engineer
Yes the MDB is configured with container transactions.
The thing is i want to know from which table from pega database does pega populate the requestor pool since if i delete this entry from that table i might be able to prevent the looping of this transaction.