How to cache static application information How to cache static application informationMany applications contain static or rarely changing information such as URLs of external systems, official corporation names or lengthy, difficult-to-type external file names. Often it is desirable to centralize such information to a single place to simplify maintenance when changes do occur.
PRPC offers several mechanisms for caching application-specific information that rarely changes. While most operate automatically and invisibly, understanding their differences may help you decide which is most appropriate for a specific situation. Choosing the appropriate mechanism can improve performance and response time and reduce JVM memory demand.
These four capabilities are available:
Node-level declarative pages, created and maintained by data page rules (Rule-Declare-Pages rule type), can hold an arbitrary set of property values. Your application can initialize a declarative page using an activity, which may simply load values from a data transform, perform complex calculations, or use a connector to obtain information from an external system. Instead of using an activity, you can also use a report definition to load the page's values.
Information on data pages is read-only except to the activity or report definition that loads the values. At most one copy of node-level data pages is present in the JVM memory of a server node.
For example, a single data page can hold a table of currency conversion rates, accessed once hourly from an external system. Another data page may allow lookup of city and state information from a U.S. Postal Service ZIP code.
To improve performance, PRPC automatically caches rule instances that are repeatedly accessed and executed.
For example, Access of Role to Object rules (Rule-Access-Role-Obj rule type) link user capabilities regarding instances of classes to access roles. More than 25 standard Access of Role to Object rules are associated with the standard access role PegaRULES:User4.
If your system contains hundreds of users with this access role, some of these rules are accessed frequently. Over time, the in-memory rules cache holds a single copy of the frequently accessed rules, eliminating the time and processing needed to retrieve the rule from the PegaRULES database.
A separate cache saves activities, stream rules, parse rules, and the many other rule types that are converted to Java code with rules assembly.
For example, assume that users of an application — who have a common RuleSet list — produce thousands of outgoing email messages per day — created by correspondence rules that refer to a common correspondence fragment (Rule-Corr-Fragment rule type) as a boilerplate paragraph. The fragment rule is assembled and compiled once (in the context of the common RuleSet list), by the first user who needs to execute it. If frequently executed, it automatically is added to the Rules Assembly cache, which allows the class loader to find the CLASS file at runtime.
For Rule-File-Text and Rule-File-Binary rules, the object in each rule instance is extracted (downloaded) to a file system upon first access, and served by the Web server (such as Apache) thereafter. Ordinary Web server caching mechanisms take over.
For example, a text file rule (Rule-File-Text rule type) may hold HTML styles in Cascading Style Sheet (CSS) format. After this CSS is saved as a static file, it can be served multiple times to Web browsers using ordinary HTTP operations. These accesses do not consume any PRPC resources, though they use the same server computer and file system.
(This mechanism also supports Rule-File-Form and Rule-File-eForm objects.)
|
data page, rules assembly |
|
Understanding caching
Working with the Rules Assembly cache About Data Page rules |
Technical category