Auto Link Cache

Paul Campbell  23 February 2010 08:53:58 AM

The table auto-link feature provides users with an easy way of allowing their rules to access data stored in databases. The previous post 'Auto Linking to Databases' covered configuring tables at design time and runtime. This post goes further and looks at how Idiom handles caching of database reads. Without the caching mechanism every table look-up operation would hit the database with a new query every time the operation is performed within a Formula. This poses a possible performance issue in the event that there are repeated look-ups on large data sets,

Auto-link properties dialogue

3 new controls have been added to the existing auto-link properties dialogue.

1.        Checkbox – Use query cache.

2.        TextBox – Cache entry lifetime.

3.        ComboBox – Cache lifetime unit indicator (seconds, minutes, hours).

Runtime Caching support in Decision Server

A Cache Manager has been introduced to the Decision Server, to facilitate caching for all auto-linked external Table Sets. Auto-linked Table Sets will communicate with the Cache Manager to cache or retrieve cached values.

Cache Entry Key

-        Table ID

-        List of table look up key values.

-        Range option.

The list of table look up key values refers to the data which the actual look up method receives when a table look up is performed (‘keys’ in the following code snippet):

object Lookup(IdiomArrayList keys, int dataIndex) { }

object Lookup(IdiomArrayList keys, int dataIndex, int rangeOption) { }

bool Exists(IdiomArrayList keys, IdiomArrayList data) { }

 

Cache Entry Value

-        Data from all mapped columns (or just a Boolean for the ExistInTable operation).

-        Time stamp.

While a table row may contain many columns, the Decision Server will only store the values from columns that have actually been mapped.

Cache Entry Lifetime

Each entry in the cache will be refreshed eventually to avoid returning stale data. This simply means that every time a cache entry is hit, its time stamp needs to be checked to see if it is over the specified lifetime, and a new value retrieved from the database if so.

Cache Size Limit

The cache size limit will be specified in bytes (a new ‘databaseCacheSizeLimit’ attribute on decisionServer.config itself since this isn’t a rules developer concern), with a small default size of 8mb.

LRU (Least Recently Used) Caching Algorithm

This is the caching algorithm that is implemented on the Decision Server to handle situations in which the cache size limit is reached. This involves the use of a queue system - whenever cache entries are hit, they are re-queued onto the back of the ‘line’. Entries that are seldom used will find themselves at the front of the queue. Once the size limit is hit and entries need to be removed, these least recently used entries at the front of the queue will get de-queued (removed) until there is enough space to fit the new entry.

Cache Entry Size Calculation

The size of each cache entry will be calculated by adding together the byte usage of each key value plus data values, as well as any other meta data required to store a cache entry. For example:

Table: Person

Key Columns: ID (string)

Data Columns: Name (string), DateOfBirth (dateTime), Height (decimal)

When an entry in the ‘Person’ table is retrieved, Decision Server will calculate and add together the byte usage for:

·        ID

·        Name

·        DateOfBirth

·        Height

·        Entry  Timestamp

·        Table ID

·        Range Option

·        Any other overheads such as the size of ArrayLists used to store the above values

The actual usages for each particular data type (string, decimal, int, bool, dateTime) may vary depending on the platform being used.

• Comments [0]