TDV Caching Concepts
This section introduces many of the concepts associated with TDV caching. Becoming familiar with these concepts can help you determine if you want to use caching and which TDV caching options might work best for you.
What Is a Cache?
A cache is a location that holds a copy of frequently accessed data that is otherwise expensive to retrieve or compute.
Why Use Caching?
Data caching is an important data design option that provides a valuable way to replicate data or store data closer to where it is consumed, to enhance application performance. Caching can also reduce the impact of resource-intensive queries being run against database tables by distributing the workload over several storage locations. Instead of running the same query multiple times to return the same result set, you can use a cache to store the results, and then reuse them.
When Should You Configure Caching?
If direct queries to the database are resulting in performance that is causing noticeable delays in data retrieval, it might be time to consider data caching.
What Types of Caching Are Available?
TDV has designed several caching options so you can create caches that meet your needs. Among these options are:
• Full refresh caching—All data in the cache is retrieved when a cache refresh action is initiated.
• Incremental refresh caching—Only data that has changed is retrieved and updated in the cache when a cache refresh action is initiated.
— Pull-based incremental caching—The incremental cache refresh action is initiated by a request from the consuming client application. This method could be considered on-demand.
— Push-based incremental caching—The incremental cache refresh action is automatically initiated as defined during configuration of the option. The data in the cache is refreshed regardless.
Additional enhancements, available through your database vendor, worth considering for caching include:
• Native loading features such as FastLoad
• Parallel caching feature that partitions the cache data and then runs parallel processes to load the data into the cache target
What is a Full Refresh Versus an Incremental Refresh?
You can also have your cache data refresh happen incrementally or in full. A full refresh would retrieve the data in the cache in its entirety, include data that changed since the last cache refresh and any data that is unchanged. With an incremental cache update, only data that is changed (newly added, modified, and deleted) is updated in the cache when the refresh action runs.
On the Caching tab under the Advanced options, you can select one or the other for your cache. If you require a push-based incremental refresh, there are several special required configuration steps that are explained in
Push-Based Incremental Caching.
What Are the Incremental Caching Options?
TDV provides for two methods of incremental caching. The updates to the cache can be propagated using one of the following two modes:
• Pull-Based Incremental Caching
Pull-based incremental caching can be set up using the TDV caching mechanism with two scripts. With pull-based incremental caching the user or client application must make a request for their copy of the cache to be synchronized with the centralized cache copy. This asynchronous method or cache data update can improve cache loading times because after the initial data is loaded into the cache each subsequent load is only updating the cache with the smaller data changes. For more information on pull-based incremental caching, see
Setting Up Pull-Based Incremental Cache.
• Push-Based Incremental Caching
Push-based incremental caching can be set up using the native TDV caching mechanism, plus the TDV Change Management Service (CMS), to configure a Central Event Server. This synchronous method of cache data update enforces cache consistency across all copies of the cache data. To protect the data in the incremental cache, you can configure the TDV server to back up the primary Central Event Server. To keep transactional semantics from differing between the sources and the caches, changes in the source are captured and applied to all affected views. For more information on push-based incremental caching, see
Setting Up Push-Based Incremental Caching for Oracle.
What TDV Resources Can I Cache?
Caching lets you store data generated from a view, table, or procedure from across data sources. Table objects include tables, views from data sources, and TDV views. Procedure objects include SQL scripts, parameterized queries, and XML transforms.
What Cache Storage Options Are Available?
A storage option determines the location and some of the behavior associated with a cache. A cache can be stored as a:
• Default—Cache data is stored in a TDV determined database location.
• Automatic—Cache data is stored in a TDV determined structured file location.
• Single Table—Cache data is stored in a user determined structured database location.
• Multi-Table—Cache data is stored in a user determined database location in a user determined number of caching tables.
For single table caching, several snapshots (a picture of your data taken at a point in time) of data is stored in the same physical table. Because several snapshots are stored in the same table, index on the cached data is less effective. With the multi-table cache option, TDV uses several physical tables for each cached resource so that each snapshot is stored in its own table. This feature can increase the speed of deleting old cache data and indexing the newly cached data. Multi-table caching is primarily meant for caches that contain a substantial amount of data which is retained for a long time. For details about setting up this type of caching, see
Creating a Multiple Table Cache on a Database Target.
What Is a Cache Target?
A cache target is a file, database table, or multiple database tables used to store data for a specified period of time.
For a data source to be a cache target, it must conform to the prerequisites specified in
Cache Requirements and Limitations. While it is possible to have the same cache resource act as both source and target, it is more common to have them be different. Data from multiple resources cannot share cache target tables.
Consider what cache target is most suitable for the type of data to cache and how you want to interact with it. For example, a cache target might not support important data types in the source. Review the
Cache Requirements and Limitations. Also check the Cache Data Type Mapping section of the
TDV Reference Guide.
What Refresh Options Are Available for a Cache?
TDV cache data refresh is highly configurable. You can use the standard scheduling tools available through the TDV Studio UI, or you can define custom refresh behavior. The following standard refresh options are available:
• According to a policy—Reusable cache policies can be used to define cache refresh schedules. The policies can be used to define the refresh options for tables, views, and procedures.
• Immediately—Refreshes the cache immediately when a TDV user opens the Caching tab and clicks Refresh Now.
• One Time Only—Allows you to schedule a specific date and time for the cache to be refreshed once.
• Periodic—Allows you to define a regular recurring cache refresh action.
• Custom—You can also define SQL scripts, Java programs, or web services that control and define cache refresh behavior. For example, you could write a custom Java program that would initiate a cache refresh if an email was sent to a particular email address with a well formatted subject line. For more information on defining custom refresh behavior, see
Refreshing and Clearing Your Cache Programmatically.
Modifying the query of the view (or table) that you have caching defined on does not automatically update the cache. You must execute a refresh or wait for the next scheduled refresh cycle to get the correct result set.
What is a Cache Policy?
Cache policies define cache refresh and expiration schedules. After a cache policy is defined, it can be used to control the refresh and expiration schedules of Studio resources that you want to cache.
Because the same refresh and expiration schedules can be set for resources in your cache, data consistency and accuracy can be improved for the applications accessing the cached data. For example, if you have an application that relies on cached data for the ORDERS table and the ORDERDETAILS table, you can use a cache policy to make sure that their caches are refreshed at the same time.
Cache policies also enhance cache performance. With cache policies TDV can calculate the optimal cache load strategy for performance because the list of resources that are part of the cache refresh action for a given policy are well known.
With cache policies, cached data consistency is all or nothing. If one of the resources included in the cache policy fails during refresh action, all of the caches are rolled back to the previous successful snapshot of data. For this reason, cache policies and incremental caching are not supported for use together.
When Does Cache Data Expire and Get Removed From the Cache?
A cache refresh is used to create or update the cache contents. Depending on how you have configured your cache determines how the data from a previous refresh expires and potentially gets removed from the cache.
Expired cache versions are not deleted until all transaction holds using that version are completed or rolled back.
Typical expiration schedules are:
• Never—Keep the current and all previous data snapshots in the cache.
• Periodic—Allows you to define a regular recurring cache expiration time. For example, after a specified number of weeks or years.
• According to Custom Criteria—You can control cache data refresh and clearing by defining custom SQL scripts, Java programs, or web services.
You can also control whether the cache data clears:
• Immediately—Clear the cache using the Clear Now button. This marks the old cached version of the data as expired so that new requests cannot use it; then the system initiates a background task to clear the expired cache version when it is released.
• On Failure—Selecting this option would clear the cache if a refresh fails. This option allows access to previously cached data during a refresh.
• Before the Refresh—Selecting this option would automatically clear the cache before starting a refresh. Any clients attempting to read from the cached data must wait for the new data. Forces all new requests to use the new cache version, marks the older cached version as expired but not actually cleared, and new requests for the cached resource must use the latest data provided by the cache refresh.
• Periodically At Expiration Time—On cache expiration, if a time is defined in the Expiration Schedule portion of the screen, the old cache data is cleared out.
• According to Custom Criteria—You can control cache data refresh and clearing by defining custom SQL scripts, Java programs, or web services.
What is Cache Versioning, Transaction Integrity, and When Are Old Cache Contents Cleared Out?
TDV cache versioning preserves transaction integrity by maintaining old cache versions until existing transactions are completed. Expired cache versions are not deleted until all transaction holds using that version are completed or rolled back. Even when you manually initiate cache clearing, that action only marks the old cached version as expired so that new requests cannot use it; then the system initiates a background task to clear the expired cache version when it is released.
TDV can be configured to gracefully handle long-running cache refreshes by retaining all previous cache data snapshots, which preserves usability of the data while a cache is actively being refreshed in the background.
To preserve read consistency, long-running queries that use data from a cached view are allowed to complete computations with the original cached view that it was using at the time the cache refresh started.
Can Caches Be Exported and Imported?
All of the cache information that you define within TDV can be exported and reimported into TDV. Using the TDV export functionality can be an effective way to manage your TDV development work. If done routinely, it can provide a valuable rollback snapshot of your work.
How Does Error Handling Work for Resources that use Cache Policies?
If a cache refresh is initiated by a cache policy and it fails at any point before completion, all the caches are rolled back to the last successful snapshot.
How Does Error Handling Work for Resources with Individually Defined Cache Refresh and Expiration Schedules?
If the data sources providing the data to be cached or the data source used to store the cached data fail during the refresh, the cache is marked as failed or stale depending on whether the previous snapshot is available.
If the TDV server fails during the refresh the cache is marked as failed or stale when the server is restarted.
For caches that perform a full refresh, if the server dies in the middle of a refresh, the refresh attempt is marked as Failed on server restart. Any partial data is eventually processed by the garbage collector.
For caches that perform incremental refreshes, if the server dies in the middle of a refresh, the cache status is marked as DOWN when the server is restarted.