Salesforce

Magic xpa Cache (Magic xpa 4.x)

« Go Back

Information

 
Created BySalesforce Service User
Approval Process StatusPublished
Objective
Description

Magic xpa Cache

The basic assumption behind the need for caching is that the same data will be needed more than once. Therefore, if data can be re-fetched without performing disk I/O operations, overall performance will be enhanced.

Unlike general purpose disk caches that employ generic algorithms for their caching, the Magic xpa cache lets you fine-tune the cache according to your knowledge of the physical data and the nature of the project.

The Magic xpa cache does not call any file manager as other hardware or software caching methods might. The Magic xpa cache therefore avoids the additional file manager overhead of traditional methods.

What can be cached?

The Magic xpa cache can be used for main sources and linked tables. The Magic xpa cache is implemented on a task and Main Source/link basis. This means that if a parent task and a subtask are accessing the same table, and both tasks enabled caching on the table, then two caches will be used. The same applies for two Link operations to the same table in a task. In this case also, two caches will be used.

When is the cache used?

Data can be read from the cache only when Magic xpa does not need to issue a lock for the row. The need for a lock is determined by the following three factors.

  • The Locking strategy, defined under the Data tab of the Task Properties dialog box.

  • The Cache strategy, defined under the Data tab of the Task Properties dialog box.

  • The definition of the Access and Share modes (in the Main Source Properties sheet) with which the table was opened.

A lock is issued only for tables that are opened with write access and share. The timing of the lock is determined by the locking strategy.

Moving from Query mode to Modify mode, and from Modify mode to Query mode, is performed using the cache. The records in view when switching modes are not refreshed.

A Sort operation automatically creates caches for the sort file.

When accessing Create mode, or when User Locate, User Range, or Sort operations are taking place, the cache is released.

Toggling between Modify and Query modes causes Magic xpa to access the cache and eliminates the need to re-fetch data from the database.

Activating the cache size

It is possible to define the cache of a linked table as disabled or enabled. This definition is set by using a Yes or No setting in the Cache property of the Link operation. When the Cache is set to No, caching is disabled for the linked table in the task. If the column is set to Yes, the table cache is used. The default value is Yes.

Changes to program behavior

Use of the Magic xpa cache changes the behavior of programs. Whenever data is found in the cache, the data may not be the same as the data in the data source. However, before updating the data, Magic xpa will always read the row from the disk. As an example, consider a simple Online program created by the Automatic Program Generator (APG). Whenever the insertion point is moved from one row to another, the data view of the new row is automatically reread.

In the case of another user who has changed the data, we will not see the change when we park on the row (if the data was in the cache), but if we try to modify the data, the current values data will be read from the disk, and the message: Record has been changed – restart.

When using the Position and Data cache strategy, in addition to the position, Magic xpa will store the actual data of the row. If you re-fetch that row you will get the old values stored in the cache. Note that any modifications done to this data from another task will not be seen in the current task. Trying to update a record which was modified in another task will return the message mentioned above.

There are cases where the project definition does not allow the cache to be used. For example, assume an order entry project where the Prices table is accessed for read with Write Share. If a price had been changed by one end-user, and the new price of an item resides in that user’s cache, no other end-user will be able to see the new price.

Cache and resident tasks
Cache and the Rollback operation
Magic xpa cache internal implementation

Every row that Magic xpa reads is inserted into the cache. In addition, any modification, deletion, or insertion of new rows, is also placed in the cache. Whenever a row that already exists is reread by Magic xpa, it will supersede the previous value. If a row that does not exist in the cache is read, the Magic xpa Cache automatically places it in the cache. If the cache is full, an LRU (Least Recently Used) algorithm is used to determine which element is to be dumped from the cache.

The use of the LRU mechanism ensures that data that is read more frequently will have a lower chance of being swapped out of the cache.

Reference
Attachment 
Attachment