home   about us   contact us  
Distribtution
Financial
Appx
News
Search site for:




APPX and Oracle - File Caching

With release 4.1, you can now specify that you want some of your files to be cached in memory, rather than retrieving the records from disk (or from and RDBMS server) each time they are required. This can give you a big performance boost - especially when you run a process which accesses the same data over and over again (looking up data in code tables during a long-running update process, for example).

Currently, you must use ILF statement to control caching - in a future release, APPX will add cache-related specifications in the data dictionary and at the process level so that you don't have to write as much ILF code.


CREATE Statement:

The CREATE statement can now be used to programmatically create and open a cached instance of a file. Specifying a CACHE option other than 'NONE' causes a cached instance of a file to be created in memory and opened instead of the normal disk instance of the file. The value of the CACHE option determines how the cached instance of the file is populated. If --- NEXT DATABASE is specified for a CREATE statement which is to create a cached file, then the value of next database determines the source database for loading the cache. Otherwise the current database is used to determine the source of the file which is used to load the cache.

CREATE ___ ________ SHARE? _ FAIL _ CACHE _______
      (1) (2)             (3)    (4)     (5)

(1) Application ID
(2) File Name
(3) Share Y/N?
(4) Fail Type
(5) Cache type
CACHE TYPE:

NONE - Create and open the file as a normal, non-cached file.

NO LOAD - Create and open the cached instance of the file but do not load any records into the cache file (use the WRITE statement to populate the cache).

LOAD - Create and open the cached instance of the file and load cache file from the disk instance of file.

AUTO - (Currently same as LOAD) Create and open the cached instance of the file. Dynamically populate the cache from the disk instance of the file as records are individually read.


OPEN Statement:

A new parameter has been added to the OPEN statement which allows you to open either the cached instance of a file or the disk instance of the file. If CACHE=Y and the cached instance of the file does not exist, then the OPEN statement will fail. So, a CREATE statement must be used to create the cached instance of a file before the OPEN statement can be used to open it. If --- NEXT DATABASE is specified in conjunction with CACHE=Y, then --- NEXT DATABASE is cleared and ignored.

OPEN ___ ________ SHARE? _ FAIL _ CACHE? _
    (1)  (2)            (3)    (4)      (5)

(1) Application ID
(2) File Name
(3) Share Y/N?
(4) Fail Type
(5) Cache Y/N?
SCRATCH Statement:

A new parameter has been added to the SCRATCH statement which allows you to scratch either the cached instance of a file or the disk instance of the file. If --- NEXT DATABASE is specified in conjunction with CACHE=Y, then --- NEXT DATABASE is cleared and ignored.

SCRATCH ___ ________ FAIL _ CACHE? _
       (1)  (2)          (3)      (4)

(1) Application ID
(2) File Name
(3) Fail Type
(4) Cache Y/N?
CLOSE Statement:

The CLOSE statement closes the currently opened instance of a file, either disk or cache.

Like memory files, there can be only a single instance of a cached file. There is not a separate instance of a cached file for each database.

Once you have opened the cached instance of a file, all I/O which follows will reference the cached instance of the file, not the disk instance.

If you execute a CREATE statement with CACHE=NO LOAD, then you can load the file yourself, perhaps with a subset of the records. One possible use of this would be to effectively constrain a DLU.

If you rewrite, delete, or write records to the cached instance of the file, the disk instance of the file will not be updated. If the disk instance of the file changes after you create and load the cached instance of the file, the cached instance of the file will not automatically include these changes.

Cached files were conceived as a performance enhancement for "read only" files which are stored as tables in databases. However, they should prove to be useful in many other applications as well!


Here is some example code which shows how to manually populate a cache with selected records:

	* 
	* This code creates a cached instance of the SALESREP
	* file and loads it with the "Inside" salesreps 
	* 
	* Create a cache instance of the SALESREP file 
	* 
	CREATE   CCA SALESREP SHARE? Y FAIL 0 CACHE NOLOAD 
	* 
	* Open the disk instance of the file 
	* 
	OPEN     CCA SALESREP SHARE? Y FAIL 0 CACHE? N 
	* 
	* Read all of the SALESREP records 
	* 
	BEG READ CCA SALESREP HOLD 0 KEY IS SALESREP SALESPERSON 
	* 
	* Add only the inside salesreps to the cache 
	* 
	IF       CCA SALESREP INSIDE EQ Y 
T	OPEN     CCA SALESREP SHARE? Y FAIL 0 CACHE? Y 
T 	WRITE    CCA SALESREP FAIL 0 
T 	OPEN     CCA SALESREP SHARE? Y FAIL 0 CACHE? N 
	* 
	END READ CCA SALESREP 
	* 
	* open the cached instance - all references within 
	* the process will now use the cached instance 
	* 
	OPEN     CCA SALESREP SHARE? Y FAIL 0 CACHE? Y

Do you have a tip you want to pass on? Contact Us.


« Return



© Copyright 2009 - C.A.N.S.Y.S. West Limited All Rights Reserved