has the cache algorithm been applied in the question or is this prior to that and this is every instance of the rule at the beginning when simply all rules are picked with the correct purpose (the purpose being the name of the rule and it's type of record)
yes, that is fine, although in the 7.2 material, it shows a decision is made to check the rule cache, if it exists then to carry on, otherwise to populate the cache indicating it's not optional (i've read somewhere that the rule needs to be referenced 3/multiple times for it to enter the cache).
what I was specifically asking in the context of this question - it presents a "rule cache" showing five instances of a rule.
has the caching algorithm (which is a sub-process of the main rule resolution algorithm) been run yet? the answer to this is no it hasn't been run.
the question starts from the first step in the caching algorithm "choose rules with the correct purpose" - if you carry on from here, you arrive at the answer easily
the question leaves a lot to be assumed which makes it not a good question when people are being critical of the words and context it is presented in
I should have said "caching is secondary" as opposed to saying "caching comes later". The existing rule being referenced has a key which can be quickly checked against the cache to see if the rule is still valid.
This raises the question "how can the rule key become invalid"?
This is no longer being taught in your SSA course, or even the LSA course, partly due to changes Pega has made since PRPC 6.2 with regard to what is called "System Pulse". Help simply says there is a database pulse and cluster-based pulse -- the latter the currently used approach. If interested you can research cluster technologies such as Apache Ignite and Hazelcast.
Suppose the older database system pulse. When you have multiple nodes and within one node someone checks in a new version of a rule, something needs to "tell" the other nodes in the cluster that the rule they are using may no longer be valid (is untrustworthy). This can be accomplished by a cache-related table in the database being updated at the same time the new version of a rule was checked in. A System Pulse agent that runs on each node periodically compares what exists within in its in-memory cache to the cache-related database table. If the table indicates a change has occurred, the in-memory cache needs to react.
When the application is forced to react it needs to re-run the rule resolution algorithm. An application's ruleset stack may be limited to specific patch level versions. If a rule has been checked into the database at newer version than what the application allows, that newer version will be excluded as part of the rule resolution process.
thanks for the reply, I was looking for information regarding the behaviour of the cache just to get a better understanding. from the current 7.2 material, it doesn't talk about scenarios that can invalidate a cache, at what point things are refreshed or what can cause a reset.
I was curious to know what happens if you restart a pega server in regards to the cache or if there are other exception scenarios.
from my understanding, if you update a rule, that would cause that rule to be invalidated in the cache and the rule resolution algorithm occurs again?