Cache Strategy – Tasks (Magic xpa 3.x)

The Magic xpa cache lets you fine-tune the cache according to your knowledge of the physical data and the nature of the project. Using the cache reduces disk I/O, thus enhancing overall performance. The options below are applicable for interactive physical transactions with a Main Source. In addition, the first two are also available for Deferred transactions:

• Position – The cache holds information about the position of the fetched records. When the user scrolls backwards, the data will be re-fetched by reading the records by their physical position. When choosing the Position option, Magic xpa still uses the network to read the record again. However, it will be shorter, since it brings one specific record instead of creating a cursor that will include a range of records.
  This option is used when you do not have enough cache in the client or you need updated data. This option allows you to improve performance by using a cache for these instances.

• Position and Data – In addition to the position, Magic xpa will store the actual data of the record. If you re-fetch that record you will get the old values stored in the cache without using the network at all. 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 an error.
  If you have enough memory in the clients and the level of update is not critical, then this is the most recommended option. This is the only option that does not perform a Get Current operation each time a record is fetched.

• None – No caching. Each time that a record should be re-read, it will be retrieved from the database.

• As Main Source (default) – The source will cached as defined in the Cache strategy property in the Data Source Properties dialog box.

The caching mechanism enables you to store data in the Record level. Fetched records can be stored in the client cache. The records are kept in the cache during the task execution, and the rows are usually released by the end of the task. For tasks that handle many records more than once, using a cache may be a real option for improving performance.

When working with a cached table, you should note the following:

• A cached table consumes memory. Therefore, you should verify that the client's machines have the needed amount of memory.

• The data that is retrieved from the cache may not always be the most updated data.

When the client’s machine does not have enough memory resources, performance may dramatically decline. The cache strategy can be defined at the Table level and can be overwritten by the Task level. The task’s default will be taken from the table.

In interactive tasks, it is relevant for the Main source and linked tables, where in Batch tasks it is only relevant for linked tables (you cannot go over the same record of the main source more than once, but the same link can be used for different records).

In Batch tasks, links are very often pointing to the same range of records. When a cache is not used for the linked table per each record from the main source, the linked record will be retrieved again from the database. When using a cache, the linked table is saved and brought from the client. This significantly improves the Batch task's total duration.