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.
Process Commander 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 declare pages 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 model, perform complex calculations, or use a connector to obtain information from an external system.
Information on declarative pages is read-only except to this activity. At most one copy of node-level declarative pages is present in the JVM memory of a server node.
For example, a single declarative page can hold a table of currency conversion rates, accessed once hourly from an external system. Another declarative page may allow lookup of city and state information from a U.S. Postal Service ZIP code.
To improve performance, Process Commander 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 e-mail 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. Once 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 Process Commander resources, though they use the same server computer and file system.
(This mechanism also supports Rule-File-Form and Rule-File-eForm objects.)
|
declarative page, rules assembly |
|
Understanding
caching
Working with the rules assembly cache About Declare Pages rules |
Technical category