Question
Verizon
IN
Last activity: 18 Mar 2016 9:24 EDT
Changes in one node is not reflected in another
Hi,
We are facing the same issues as mentioned in the following support articles :
https://community.pega.com/support/support-articles/rule-updated-one-node-not-reflected-another-node
https://community.pega.com/support/support-articles/rules-resolution-identified-2-version-rule
The solution mentioned in these articles is to update the database trigger "TRPR4_RULE_DEL".
Can you please tell us what precautionary steps we should follow before going ahead with this changes and checking if this helps resolving my issues.
Product version : Pega 7.1.6
Accepted Solution
Verizon
IN
Hi All,
Thanks for your responses. We went ahead with the fix suggested in SA-15931 and it fixed the issue.
Pegasystems Inc.
IN
Hi
We suggest every customer to take database backup before implementing / changing anything on the database level. The same applies here as well.
Pegasystems
US
Both of those SA's are for 7.1.7 and your version is 7.1.6 so you'd want to get confidence first that the db trigger in question applies to your version. [ Does your copy of the db trigger match the initial contents shown in those SA's ? ]
Secondly, the first SA says the issue is for db2 zos. Is that your env ? Although the second SA doesn't explicitly say that, the trigger contents itself mentions db2 in one of the names so I'm wondering if it applies only to db2 type of data base.
I will ask one of our ops team members to comment here. /Eric
Verizon
IN
Yes. The copy of the db Trigger in my env matches the one mentioned in the SA.
We are using db2 database. That's why I thought those SAs are applicable to the issue we are facing.
I've raised a SR for the same. I just want to get a confirmation from pega support before going ahead with this change.
Once the respective associate handling the SR contacts and confirms I'll do the changes accordingly.
more basic question - is system pulse running on every node?
Do you see all changes to rules reflected in table pr_sys_updatescache?
Keep in mind that prior to 719 triggers are there simply to reflect insert / update / delete to *rule* tables and certain pr_data_admin classes into pr_sys_updatescache.
Verizon
IN
System pulse is running on all the nodes.
And I can see entries in the updatescache table.
For now either I have to reload candidates using Virtual Table Cache option in SMA or do a check out /check in of the rule in all the nodes or do a revalidate and save to get the changes reflected.
Pegasystems
US
Are your changes imported or made in-place (with "create new rule" or "save" or "save-as") ? If imported, with landing page or script ?
What kind of rules are affected ? Sections ? Activities ? Other ?
If you use your extra step of SMA, check in, or reval-and-save, does the fix stick ? Or do you find the extra step is needed again later for the same rule, for instance after a system restart ? Or do you only need the extra step if you change the rule again ?
For a rule that has the issue, does the issue occur every time you change that rule ? Or does the problem seem to move from rule to rule ?
Any kind of usage pattern could be useful for analyzing this. For example: "We observed that newly-updated rule A is being picked up properly but newly-updated rule B is not, and we realize that rule B was referenced on the other node before the update but rule A was not so maybe the issue only occurs with rules that were referenced ?" or " . . . the reverse of that last statement ! . . . "
/Eric
Verizon
IN
Are your changes imported or made in-place (with "create new rule" or "save" or "save-as") ? If imported, with landing page or script ? -- made in-place
What kind of rules are affected ? Sections ? Activities ? Other ? - Almost all the rule types
If you use your extra step of SMA, check in, or reval-and-save, does the fix stick ? Or do you find the extra step is needed again later for the same rule, for instance after a system restart ? Or do you only need the extra step if you change the rule again ? - The fix sticks. We need not do anything further.
For a rule that has the issue, does the issue occur every time you change that rule ? Or does the problem seem to move from rule to rule ? - It happens every time we make changes like delete/ check-in.
Any kind of usage pattern could be useful for analyzing this. For example: "We observed that newly-updated rule A is being picked up properly but newly-updated rule B is not, and we realize that rule B was referenced on the other node before the update but rule A was not so maybe the issue only occurs with rules that were referenced ?" or " . . . the reverse of that last statement ! . . . " -- No particular usage pattern. This happens every time we check-in/delete a rule .
Highmark Health Solutions INC
US
I face the same issue in Pega 7.1.8.
I tried to look for the triggers on the tables mentioned in the SA-15931 and i dont find them and i found an article in PDN suggesting as an enhancement we dont have the DB triggers. what can be done in this case..
https://community.pega.com/knowledgebase/release-note/startup-check-removes-custom-db-triggers
Can any one suggest if we have any fix for this in 7.1.8
Pega 718 does not use triggers -- the engine itself directly writes to pr_sys_updatescache, Check that table first - are all the expected entries there?
There is a known possible race condition that can cause system pulse to skip records if pulse on one node is running while rules are changing or being loaded on another node,
There is an undocumented system setting ystempulse/scanoffsetms specifically to address this scenario by adding a configurable 'overlap window' to ensure that rules that were waiting for dbms commit at time of last pulse will get processed in next pulse.
Highmark Health Solutions INC
US
Thanks Andrew Werden.
Can I update this system Setting in under the System Setting Rule or do i need to specify as a prconfig entry?
