Bug 177870 Allow design-time data set cache to be controlled solely by AppContext
This is to request that BIRT allows data set caches to be controllable solely by runtime parameters/settings, without the application having to update the report design to set data set cache preferences. Since BIRT DataEngine already reads request Application Context to determine if data set cache should be disabled, we will expand AppContext to allow the application to enable data set cache and to set max row count. The following new application context key will be introduced: org.eclipse.birt.data.cache.RowLimit The value of this app context is expected to be an integer. Its value can be: 0: Disable data set cache regardless of report design settings and DataEngineContext settings. Positive integer: Enable data set cache. This row limit will be used for ALL data sets, regardless of settings on individual data set designs. If this key is absent in the appcontext, or if its value is not a non-negative integer (including NULL), we will following current rules to determine cache settings. As part of this change, we will also deprecate existing app context key "org.eclipse.birt.data.engine.dataset.cache.option". Its declaration in DataEngine class should be marked deprecated. We will continue to read and handle its value, but the user is encouraged to use the new key "org.eclipse.birt.data.cache.RowLimit" (by setting its value to 0).
data/org.eclipse.birt.data/src/org/eclipse/birt/data/engine/executor/DataSetCacheManager.java
* Contributors:
 *  Actuate Corporation  - initial API and implementation
 *******************************************************************************/
package org.eclipse.birt.data.engine.executor;
import java.util.Collection;
import org.eclipse.birt.data.engine.api.IBaseDataSetDesign;
import org.eclipse.birt.data.engine.api.IBaseDataSourceDesign;
/**
 * Cache manager for ODA data set and Scripted data set. Since connection to
 * data set and retrieve data are expensive operations, it is unnecessary to do
 * them again and again when user just want to see the data in the same
 * configuration of data set. The basic idea is when user want to use cache, the
 * data will be saved into cache in the first time and it will be loaded in the
 * later time. Once the configuration of data set is changed, the data needs to
 * be retrieved again.
 * 
 * Please notice the whole procedure: 1: first check whether data can be loaded
 * from cache 2.1: if yes, then data will be loaded and check whether data needs
 * to be saved into cache will be skiped. 2.2: if no, then data will be retrived
 * from data set and then whether saving into cache will be checked 2.2.1: if
 * yes, then data will be saved into cache 2.2.2: if no, then nothing will be
 * done
 * 
 * There are three possible value of cacheRowCount: 1: -1, cache all data set 2:
 * 0, don't cache 3: >0, cahe the specified value
 * 
 * Here whether data will be loaded from cache can be observed by external
 * caller, but about saving into cache is not.
 */
public class DataSetCacheManager