Caching
The PeopleSoft data model and application are mostly stored in the database in PeopleTools tables. These tables are queried as the application executes. For example, when you open a component, the component and pages, including all the PeopleCode, the definition of any records used, and so on have to be loaded into the component buffer. Ultimately this information comes from the PeopleTools tables. To save the overhead of repeatedly querying these tables, PeopleSoft caches this data locally in physical files the application server and process scheduler domains. The application servers also cache some of this information in memory to save visiting the local physical cache. Application Designer also maintains a physical cache.Over time, as the application executes, the cache files build up. Occasionally, when it is necessary to delete the cache files and then it becomes clear just how significant is the overhead of the PeopleTools queries as a period of poor performance is seen as the application builds up fresh cache files.
Physical cache files are created in directories in the application server and process scheduler Tuxedo domains. By default, each process maintains its own private cache. Separate directories of cache files are created for each type of PeopleSoft server process in each domain. Pairs of cache files are created in each directory for each object type as needed. There is also a CACHE.LOK file in each directory that is used to ensure that only one process is accessing that cache directory concurrently.
It is possible to run with a shared physical cache, but then it is read-only and must be pre-generated. It is very rare to see this implemented, because everyone expects to continuously deliver changes over time, and if you had a shared cache you would have to deliver an updated set of shared cache file to every domain every time you delivered a new PeopleTools object.
The cache files come in pairs. The name of the cache files is the Object Type Name. This corresponds to the OBJECTTYPENAME on the PSLOCK and PSVERSION tables. The .DAT file contains the data to be cached. The .KEY file is an index for the .DAT file, and it also holds the version number of the cached object.
…
-rw------- 1 psadm2 oracle 5228492 Jun 12 06:37 RDM.DAT
-rw------- 1 psadm2 oracle 69120 Jun 12 06:37 RDM.KEY
-rw------- 1 psadm2 oracle 0 Oct 26 2015 ROLM.DAT
-rw------- 1 psadm2 oracle 24192 Oct 26 2015 ROLM.KEY
-rw------- 1 psadm2 oracle 0 Oct 26 2015 RSM.DAT
-rw------- 1 psadm2 oracle 24192 Oct 26 2015 RSM.KEY
…Version Numbers
Version numbers track when a cached PeopleTools object has been changed, either by Application Designer, or a change in configuration, or the application. The version numbers are sequences generated from two PeopleTools tables PSLOCK and PSVERSION that hold the highest version number for each type of object. These two tables have the same structure.
SQL> desc psversion
Name Null? Type
----------------------------------------- -------- ----------------------------
OBJECTTYPENAME NOT NULL VARCHAR2(8 CHAR)
VERSION NOT NULL NUMBER(38)I have no idea why two identical tables of version numbers were created. I can see no reason for this, but it has been like this since the version numbers were changed (if I remember correctly) in PeopleTools 7. In early versions of PeopleTools, not all version numbers were on both tables, but in at least PeopleTools 8.55 only one object type appears on PSVERSION and not PSLOCK.
When an object is changed, the object and global version numbers are incremented, and the incremented object version number is recorded on the object in the PeopleTools table. The version number on the object is also stored in the physical cache files when the object is cached. If the version on the database is higher than that in the cache file, then the PeopleSoft process knows it must query the latest version from the PeopleTools table and update the cache file.
How to Update Version Numbers
It is not generally recommended, nor strictly speaking, supported to update PeopleTools tables directly with SQL. Apart from the risk of updating them incorrectly, or to invalid values, you also need to ensure that the changes are picked up by PeopleTools processes and that they do not simply continue to read the cached data. However, occasionally, it is the pragmatic way to doing something.
Here is an example from Chapter 5 of PeopleSoft for the Oracle DBA that shows how to maintain version numbers so the change is picked up by PeopleTools processes. I want to mark alternate search key indexes as unique where there is a unique key on a record because they are unique because the unique key is a subset of their columns. Then Application Designer will build the indexes as unique.
UPDATE psversion SET version = version + 1
WHERE objecttypename IN('SYS','RDM');
UPDATE pslock SET version = version + 1
WHERE objecttypename IN('SYS','RDM');
UPDATE psrecdefn
SET version = (
SELECT version FROM psversion WHERE objecttypename = 'RDM')
WHERE recname = '';
UPDATE psindexdefn a
SET a.uniqueflag = 1
WHERE a.uniqueflag = 0
AND a.indextype = 3
AND EXISTS(
SELECT 'x'
FROM psindexdefn k
WHERE k.recname = a.recname
AND k.indexid = '_'
AND k.indextype = 1
AND k.uniqueflag = 1)
AND a.recname = '';
I must increment the RDM and SYS version numbers and write the new RDM version number to the updated rows on PSRECDEFN. Next time a PeopleSoft process needs to read a record definition it will check the version numbers. The increment of the SYS object tells PeopleSoft than an object number has changed, and then it will detect that the RDM version number has changed so it has to reload and cache objects with version numbers greater than the last cached version number for that object.
@go-faster.co.uk on BlueSky
Posts
