Caching in Microsoft Axapta

The record cache in Microsoft Axapta is a performance-enhancing feature, aimed at avoiding unnecessary database access when reading the same record repeatedly. 

Record caching is only possible when the table containing the records is static. Otherwise, it is necessary to read the current record from the database when creating a relation to that particular record. This will ensure data integrity.

The enabling of caching on a table is dependent on the existence of a unique index. The caching key is determined either by the primaryIndex in the table, if one exists, or the first unique index. 

Note: 

Caching is only active for selects done with predicates on the whole caching key.

Only selects that retrieve all fields in the record are placed in the cache. Ranges are not cached.

There are 4 types of caching:

None: caching is disabled.

NotInTts: all key selects are cached. When in tts, the record is read once. The record is select-locked when read in tts, which ensures that the record cached is not updated while the tts is active.

Found: all successful key selects are cached. All caching key selects are returned from caching if the record exists there. A select-for-update in tts will force reading from the database, as well as update the cache.

FoundAndEmpty: all selects on caching keys are cached, even selects not returning data. All caching key selects are returned from caching if the record exists there, or the record is marked as non-existing in the cache. A select-for-update in tts will force reading from the database as well as update the cache.

Tip: 

Found caching is appropriate for tables that are static (or only receive inserts). FoundAndEmpty caching is appropriate for completely static tables.

The application code must be aware that cached data has no time-out. If the application is not specifically designed to handle updates to cached tables, data corruption will occur. Currently, the only way to refresh all types of caches, in both Two- and Three-tier solutions, is to restart Microsoft Axapta.

As long as all keys used from a table are verified within a tts, updating a table that is notInTts cached, does not jeopardize data integrity in the same way.

Only when Microsoft Axapta is performing an update or delete, is the cache synchronised with the table in the database. The synchronisation is not done for inserts. This means that any record, not found on a table with foundAndEmpty caching, will continue to be reported as not found, even after it has been created.

The behaviour on Microsoft Axapta Object Server thin clients is a little different if the Microsoft Axapta Object Server has exclusive use of that database. In this case the AOS will ensure that no invalid data can be read from cache. However, the problem with regards to inserts in a table with foundAndEmpty caching remains.

Methods to refresh caching

In addition to the above-described methods, there is also the “flush table name” X++ construction. This code will flush the table corresponding to the table-name from the cache. When in an AOS environment, the flush will only apply to the cache that resides where the code is run. Thus a flush run on the client will only flush the local cache, not the caching on the server.

Tip:

A delete_from  X++ construct will flush all caching of that particular table. 

The deleteCompany method on the application object will flush all tables from all caching.