Corticon EDC supports caching of database data to accelerate decision service execution by minimizing the retrieval of data that has already been retrieved. Caching can provide significant performance benefits when common data such as an actuarial table or a static list of suppliers will be needed many times by a decision service.

Corticon EDC automatically caches data within the scope of a single decision service execution. That is level 1 caching. If you want the benefits of caching to occur across decision service executions, you need to enable level 2 caching. The difference between level 1 and 2 is how long the cached data lives in memory before having to be queried again from the database when needed. With level 1, it only lives for a single execution. With level 2, it lives across executions. Level 2 caching is optional but can provide significant benefit when common data will be needed by many separate executions of your decision service.

How to use level 2 caching

There are two ways caching can be used in Corticon rules:

  1. 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 Shipment Request for an Order entity that has a one-to-many association with Customer entities. When the Decision Service receives an Order entity, it would query the database to get the associated Customer entities (for example, the Decision Service needs the customer’s address to estimate delivery lead time). When using an entity cache, the Customers could be queried once, and that data used in expediting other Order entities.
  2. 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: it should not be expected to receive updates from the rules. If an update is attempted on an 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: A Decision Service that prices online orders using a query cache could query state sales tax rates (or VAT rates) once, and then use that data 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 then 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.