Administration Guide
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
This chapter describes how to set up and manage caching for data services in BEA Liquid Data for WebLogic.
The chapter contains the following sections:
Note: Caching is only available for data service function results. It does not apply to ad-hoc queries or to security XQuery functions, which are never cached.
By caching the data returned by data service functions, you can improve response times for clients and reduce the processing burden on back-end systems.
When results caching is enabled, the first time a data service function is run, Liquid Data saves the results in the query results cache. The next time the function is run with the same parameters, Liquid Data checks the cache configuration and, if the results have not expired, retrieves the results from the cache rather than from the external source. Note that a cache entry exists for the results of each function invocation with distinct parameters. In cases when a cache-enabled function is invoked twice with two different parameters, two cache entries will be created.
Caching is disabled by default. Once it is enabled, you can configure the cache for individual data service functions as needed. Configuration tasks associated with caching include the following:
The time-to-live (TTL) setting can be set individually, that is, by data service function. In general, the more dynamic the underlying data, the more frequently the cache should be set to expire. In some cases, caching should not be used at all.
For example, if the data changes frequently and real-time access to it is critical. On the other hand, for functions that return static data, you can configure the results cache so that it never expires. If the cache policy expires for a particular function, Liquid Data flushes the cache result automatically on the next invocation.
In the event of a Liquid Data Server shutdown, the contents of the results cache are retained. Upon server restart, the Liquid Data Server resumes caching as before. On first invocation of a cache-enabled function, the Liquid Data Server checks the results cache to determine whether the cached results for this function are valid or have expired, and then proceeds accordingly.
Note that a data service developer can prevent caching for a data service function by setting the Cache Enabled attribute for the function to false. (By default, caching is enabled for data service functions.) When caching is disabled in the data service design, caching cannot be enabled in the Administration Console for any of that data service's functions. For more information, see the Liquid Data for WebLogic Data Services Reference Guide.
Liquid Data also provides a cache API that allows clients to bypass cached results, getting fresh results when needed. Also, the cache API allows for client-side cache flushing. Applications should manually refresh the cache after an update to ensure access to the most recent data.
Note: Caching is particularly effective in cases when significant processing has been applied against large data sets, producing filtered results. For optimal performance, it is recommended that you not enable caching on functions that simply return large data sets directly from a relational database data source.
You can use any data source configured for WebLogic as the caching database. Liquid Data can set up the cache table in the data source for you (if the server is in development mode), or you can create it yourself as described in the following section. Note that it is recommended that Liquid Data application not share cache tables. There should be separate tables for each application.
To use results caching, you must have one of the following database servers installed and running:
Since the Liquid Data cache may contain sensitive data, it is important to maintain access control over the cache database so that only authorized users can access it. Also, it is recommended that the JDBC data source used for cache not be used for other purposes.
The steps for setting up cache depend on several factors, including whether you are in development or production mode and whether you need to customize the cache table schema. Figure 7-1 shows the steps for setting up caching.
The steps illustrated in Figure 7-1 are described in the following sections:
For a WebLogic server that is in development mode, you can have Liquid Data set up the cache table automatically from the Liquid Data Console using whichever data source you choose. For production environments, or if you want to customize the cache schema, you will need to run the SQL scripts manually.
You can create the cache table using SQL scripts in the subdirectory corresponding to a particular DBMS at the following location:
<WebLogicHome>
/liquiddata/dbscripts/
<WebLogicHome>
/liquiddata/dbscripts/oracle/dbscript.sql
It is recommended that each application keep its cached data in its own cache table. For example, you can name the table <appname>_CACHE.
You should not change the column names or otherwise modify the structure of the schema tables (except in specific cases, as noted in Modifying the Cache Table Structure on page 7-6). See Table 7-1 for information about the cache table schema.
When the table is created automatically by Liquid Data (as described inStep 3: Specify the Cache Data Source and Table on page 7-8), an index for CHASH is created. The automatically created name is the table name with "_INDEX" appended to it.
Note: On DB2, the name is truncated to a maximum of 18 characters.
Liquid Data requires that its cache tables have a specific schema. Therefore, you should generally not modify the structure of the cache table. In some cases, however, the default column sizes may need to be adjusted based on the deployment. This may be a requirement in cases when you have data services that frequently serve result sets that are larger than the content columns in the default database tables and you are using either DB2 or Pointbase as your DBMS.
For DB2 and Pointbase, the scripts create the CINVKEY and CCONTENT columns (which store the results data) with a specific size, as shown in Table 7-1. If any serialized keys or content need to be larger than that size, the table schema should be adjusted accordingly before running the script.
Before attempting to implement customizations to the cache table, you should be familiar with the schema as shown in Table 7-1.
After creating the cache table, you can use the WebLogic Administration Console to create a JDBC data source on the WebLogic Server that points to the database that you have set up for the Liquid Data cache.
Note: If using Oracle as your cache database, you must set the Honor Global Transactions setting to FALSE
(it is set to TRUE
by default). When you create the Oracle JDBC data source in the WebLogic Administration Console, you must uncheck the Honor Global Transactions box.
Once created, you can enable the result cache as described in the following section.
After configuring the table that you want to use for caching as a JDBC data source in the WebLogic Administration Console, you can set up the cache tables using the Liquid Data Console.
To specify the cache database and enable caching:
The General tab appears, as illustrated in Figure 7-2.
Figure 7-2 Enabling Results Caching for an Application
Once caching is enabled, you need to configure results caching for each function.
After enabling Cache settings for the application, you can configure data service function caching. For each function, you can specify whether caching should be enabled, and set the time-to-live (in seconds) for cache entries.
To enable caching by function:
The Cache page appears, as illustrated in Figure 7-3.
Figure 7-3 Enabling Caching by Function
Note: All data service functions support caching by default, and can be enabled for caching as described in this procedure. Developers can, however, disable function caching using the WebLogic Workshop.
Purging the cache removes cached entries from the cache database. When the cache is purged, each function will execute against its data sources until it is cached again. Liquid Data flushes the cached query result for a given stored query whenever any of the following events occur:
Liquid Data flushes the cached function result on the next invocation whenever any of the following events occur:
You can also purge the cache manually, either for the entire application at once, or for individual functions. This section describes the following:
You can purge the cache for an application using the General Application Settings page. To purge the cache for an application:
The General Application Settings page appears, as illustrated in Figure 7-4.
Figure 7-4 Purging the Cache for an Application
You can purge the cache for individual functions using the Cache page, as illustrated in Figure 7-5.
Figure 7-5 Purging the Cache for a Function
![]() ![]() |
![]() |
![]() |