Question
Last activity: 5 Jul 2016 5:06 EDT
Lock cache, lock not present in pr_sys_locks while performing assignment (Pega v7.2)
I am not seeing any locks acquired for a Work object (Process & RUles --> Tools --> WorkAdmin --> My Locks,) after opening the WO from assignment link it is showing the "Lock is already owned" in tracer.
Is it assuming the lock is owned based on the lock cache? if so, when will lock cache will be refreshed in general..and are we using hazelcast for lock cache as well?
We are getting commit errors(lock not held) in the flow that might be because of the above issue...
Accepted Solution
Updated: 5 Jul 2016 5:06 EDT
I think, i found the root cause.
we have multiple server instances and PRPC v7.2 is in use.
Our primary server was running in PDT time zone, and few team members were using local servers(IST Time zone) pointing to same DB .
Whenever assignment with SLA was opened using the server running in PDT time zone, the issue is observed only when the SLA agent running in IST time zone processed the assignment.
This is because the lock was treated as a soft lock as the expiry time was way behind the current time w.r.t IST time zone as the lock expiry time (pxExpiryDateTime) or other time stamps in pr_sys_locks are not in GMT format.
To resolve the issue, we used the same time zone in all servers
Is this expected behavior if different servers are running in different time zones?
Pegasystems Inc.
IN
I think , i am able to observe the similar behaviour inhouse as well . Not sure if the concept of SoftLock involves here . (a soft lock is a lock, that a user has held by for too long. Based on timeout parameters, if the time exceeds than the setting that has been done, system marks it as "expired") .
From pega 7.1.7, pega has introduced an api to implement " in memory-No SQL store "
Can you please provide the tracer screen shot ? Also specify the prpc version .
Accepted Solution
Updated: 5 Jul 2016 5:06 EDT
I think, i found the root cause.
we have multiple server instances and PRPC v7.2 is in use.
Our primary server was running in PDT time zone, and few team members were using local servers(IST Time zone) pointing to same DB .
Whenever assignment with SLA was opened using the server running in PDT time zone, the issue is observed only when the SLA agent running in IST time zone processed the assignment.
This is because the lock was treated as a soft lock as the expiry time was way behind the current time w.r.t IST time zone as the lock expiry time (pxExpiryDateTime) or other time stamps in pr_sys_locks are not in GMT format.
To resolve the issue, we used the same time zone in all servers
Is this expected behavior if different servers are running in different time zones?