Caching of Validated Data: Implementation Details
Caching of Validated Data: Implementation Details
The following describes implementation details for the caching of validated fields. For a summary of the feature and how to enable it, see Optimizing the Loading of Validated Data: Getting Started.
Storage
The cache is implemented as a two-stage storage mechanism.
| Local CSV files | The stage that facilitates cross-session caching is a set of local files that hold the validated values tables as CSV representations of the data. These files are located below the Windows user directory and are named with a combination of the server, project and table. Thus, each cache file is user, server, project and table specific. Two Windows users do not share the same files even if they use the same Smart Client login name, and two projects use separate cache files even if they are hosted on the same server and have the same tables configured to be cached. |
| In-memory version of the data | The stage that facilitates cross-view caching is an in-memory version of this data that is read in from the appropriate file the first time it is needed. For the duration of the Smart Client session, that is until the user signs out from the project, the in-memory cache is maintained when switching from one view or task to the next. |
The cache files are never presented directly to the user, but are always first transformed into the in-memory representation before being loaded into the editor to be presented for selection. The client requests that fill the cache file, and thereafter the in-memory cache, follow all the security restrictions of group, role, and VPA constraints (even on non-visible fields) common to Web Central and the Smart Client grid.
Sign-in
When a user signs in to the Smart Client, the application does the following:
- Constructs the in-memory cache object but does not load any tables into the cache’s container. The loading of individual tables occurs when needed. See Loading.
- A background process ensures that all the cache files on the client have been written today. Signing in to a project begins a background thread that iterates over the list of cacheable tables and reads the local Windows user directory for cache files with the appropriate name and inspects their modified date. When the update thread either does not find a file corresponding to the user, host, project, and table combination, or that file was not written today, the thread fetches the table data from the server. Rather than write directly to the cache file, the update thread writes to a temporary file, and then quickly swaps the temporary file for the canonically named cache file. By preserving the old file, a local cache is available while the loading occurs, even if it is a day-old file.
This background update thread may slightly tax the client process in the moments after the sign-in succeeds. The duration of this background process and any application slowdown depends on the size of the cached tables and the speed of the workstation. In our tests it has never overburdened the application. This initialization is necessary to provide a current local cache. There is always some cost to the use of large validating tables, and this sign-in cost has been deemed the least onerous.
Load
The grid assigns editors on a column-by-column basis. For each opened grid view, the grid’s columns and their editors are created anew. When a column is a validated value, its editor loads the selection data according to the following priorities:
- Cacheable table and in-memory cache available. For a column based on a cacheable table, if there is data already cached in memory (that is, another view has used this field as a column and the editor has been opened), the editor loads the selection data directly from the in-memory cache.
- Cacheable table and local cache file only available. For a column based on a cacheable table, when there is no data available from the in-memory cache, but there is an appropriate local cache file from which to read data, the editor loads the selection data from the file. The loading of the file into the editor involves transforming the CSV file into a data source appropriate for the editor's grid, which is the form chosen for use in the in-memory cache. Thus, a small additional step after reading the file and transforming it for the editor is the inclusion of the data into the in-memory cache.
- Cacheable table and neither in-memory or local cache file. For a column based on a cacheable table, when there is neither data available from the in-memory cache nor an appropriate local cache file, the table might be in the process of being fetched. This can occur when the editor is opened before the cache file is fetched and written the first time a user caches a table. In this case, the first 1000 records are fetched from the server in the main thread and loaded into the editor, then the Refresh button is set to the hourglass while the remainder of the records are being fetched by the caching thread. When the caching thread has finished updating the local file and the in-memory cache, the Refresh button will change from the hourglass to a green arrow and allow manual reloading of the editor’s grid.
- Table is not cacheable. For a column that is not based on a cacheable table, there is no inspection of the in-memory cache or of the local file system for a cache file. Instead the selection data is fetched directly from the server. If there are more than 1000 records in the source table, they are fetched in pages of 1000 records, a number which has been calibrated as a safe maximum to not overwhelm the pipeline between server and client. The editor holds these records for use during the lifetime of the current view, and then the editor and its records are disposed of when the view is reset.
Edit and the Cache
When working with a column based on a cacheable table, every time the validated values editor is displayed it first fetches a source table record count from the server. The editor’s Refresh button state is reset based on a comparison of the current source table count on the server versus the count of records in the editor.
The following describes each of the refresh states:
| Refresh Button | Description |
|---|---|
| Hourglass state | When it is found that the server record count differs from the editor record count, the editor triggers an update of the cache file and the Refresh button is changed to the hourglass image. While the update is in progress, the editor is still displayed and enabled for the selection of a value. Thus, during this background update process that maintains the synchronization of the cache, the user can work without interruption, and each subsequent opening of the editor skips checking the server record count while the update is in progress |
| Green arrow refresh |
When the update has completed, the refresh button is changed to a green arrow to signal that the displayed data can be updated with a click of the button, a refresh that will be completely local because all the server interaction has occurred while the editor was available for cell edits. This action refreshes the editor from the in-memory cache without communicating with the server. If the editor is closed when the update finishes, the next time the editor is opened, the cache file is read in before opening, and the editor will be up to date (assuming that the record count on this second opening of the editor hasn’t changed) |
| Blue arrow refresh | Clicking on the Refresh button when it shows the blue arrow refreshes the editor by clearing the data it holds, and then fetching data from the server to refresh the in-memory cache, reloading that data into the editor and, finally, writing the local cache file. Note that this is in contrast to a green arrow refresh that refreshes the editor from the in-memory cache without communicating with the server |
The comparison to update the state of the Refresh button is based solely on the count of records on the server and client. The comparison is not based on record content. This is a conscious design choice based on the rarity of edits to validated values over insertions or deletions, and the expense of comparing a large number of records over simply replacing the client records.