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
Whenever a Magic xpa cache is assigned in a resident task, the cache will not be terminated when the task is exited, but only when Magic xpa returns to the menu. Thus, if a task is reading the same data from a linked table, and all of the data is cached, then the second time the task is called, the cache will be reused.
Cache and the Rollback operation
For the Rollback operation, all the caches that were updated during the transaction are invalidated. The invalidation causes all data to be erased from the cache. Only caches that had Update, Delete or Insert operations will be invalidated.
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.
