As you move Decision Services that use a database connection toward production, you might want to get the performance benefits of caching entities and queries used in Decision Services. Even though the first cache use has some performance overhead, subsequent references that use that cached content will see excellent performance.
There are two ways caching can be used in Corticon rules:
An Entity cache is appropriate when common database-enabled entities are used in the input messages sent to a Decision Service.
Case for using entity caching: Consider a Decision Service that expedites shipping requests. The Decision Service might receive a Order entity that has a one-to-many association with Supplier entities. When the Decision Service receives an Order entity it would query the database to get the associated Supplier entities. When using an entity cache, the Suppliers could be queried once and used in expediting other Order entities.
A Query cache optimizes lookup (query) of database data, such as when a cached entity is extended to the database in a Rulesheet. A Query Cache is read-only -- a lock is put on the records(returned from the query) associated with that decision service. If an update is attempted on a entity contained in a query cache an exception occurs. A Query Cache is optimistic -- that means that updates from outside of the Decision Service will not modify or invalidate the cache contents.
Case for using query caching: Consider a Decision Service that prices online orders. With a query cache, it could query state sales tax rates once and use these when calculating the price of all orders it receives.
Case for using query caching: Consider a Decision Service that prices insurance policies. With a query cache, it could query an actuarial table once and use the results in pricing multiple insurance policies.
First, you specify the caching settings in the Vocabulary and Rulesheets, and then enable caching in tests and deployed Decision Services.
Specifying Entity caching
To use entity caching:
1. Identify the Vocabulary entities that you want cached.
2. Edit the Vocabulary, and then choose Show Vocabulary Details.
3. Confirm (or set) the entity's Datastore Persistent property to Yes
4. Choose the preferred Datastore Caching value:
No Cache or blank (default) - Disable caching.
Read Only - Caches data that is never updated.
Read/Write - Caches data that is sometimes updated while maintaining the semantics of "read committed" isolation level. If the database is set to "repeatable read," this concurrency strategy almost maintains the semantics. Repeatable read isolation is compromised in the case of concurrent writes.
Nonstrict Read/Write - Caches data that is sometimes updated without ever locking the cache. If concurrent access to an item is possible, this concurrency strategy makes no guarantee that the item returned from the cache is the latest version available in the database.
Specifying Query caching
There are two ways to use query caching: on an entity in a Rulesheet, and on a database filter in a Rulesheet. You can use either or both as needed once you have enabled the Vocabulary.
To enable query caching:
1. Identify the Vocabulary entities that you want cached.
2. Edit the Vocabulary, and then choose Show Vocabulary Details.
3. Confirm (or set) the entity's Datastore Persistent property to Yes
Note: Query caching is independent of entity caching so the Datastore Caching setting is not relevant.
To use query caching on an entity in a Rulesheet:
1. In a Rulesheet, choose Advanced view to show the Scope tab.
2. On the Scope tab, datastore-persistent entities show a database decoration, and each one offers the Extend to Database option in its dropdown menu. Choose that option to select it.
3. Once extended to database, the option to Cache Query is offered on the dropdown menu, as shown:
4. Choose the option to Cache Query on this entity in this Rulesheet.
To use query caching on a database filter in a Rulesheet:
1. In a Rulesheet, choose Advanced view to show the Scope tab.
2. On the Scope section, datastore-persistent entities show a database decoration, and each one offers the Extend to Database option in its dropdown menu. Choose that option to select it.
3. On the Filters tab, choose a filter that references an entity extended to database, the right-click to display its dropdown menu.
4. Choose Database Filter. The filter is decorated with a database symbol.
5. Dropdown the menu on that filter again. The option to Cache Query is now available, as shown:
6. Choose the option to Cache Query on this filter in this Rulesheet.
Enabling Caching on a Ruletest
Once Rulesheets and the Vocabulary have enabled database caching,each Decision Service has to enable the caching. You can enable caching in Studio through options in Ruletests, and then set parameters that will enable caching on the Decision Services in deployment.
In Studio, use a Ruletest that specifies a test subject that is (or includes) a Rulesheet that specifies entity or query caching, and then choose Ruletest > Testsheet > Database Access > Enable Caching, as shown:
Note: For information on how enhanced database caches are implemented in deployments, as well the cache settings and behaviors for both Ruletests and deployed Decision Services, see the topic Working with database caches .
Case for using entity caching: Consider a Decision Service that expedites shipping requests. The Decision Service might receive a Order entity that has a one-to-many association with Supplier entities. When the Decision Service receives an Order entity it would query the database to get the associated Supplier entities. When using an entity cache, the Suppliers could be queried once and used in expediting other Order entities.
