SAS/ACCESS Interface to SYSTEM 2000 Data Management Software: Reference

Levels of Locking

SAS software supports several levels of locking through the CNTLLEV data set option. If CNTLLEV equals REC (the default), SYSTEM 2000 software performs record level locking. The interface view engine interprets any CNTLLEV setting other than REC to signify that it should do an exclusive open of the database. Also, the database is under exclusive use if you have issued the S2KLOAD statement in the DBLOAD procedure. Exclusive use locks out all other users entirely until the database is closed, which normally occurs when the procedure ends. (The database close operation depends on the procedure.)

Note: Some SAS procedures set CNTLLEV equal to MEM internally for their own processing reasons. Many statistical procedures must make multiple passes of the data. For example, finding the median requires more than one pass. [cautionend]

In a Multi-User environment, exclusive use of a database can cause undesirable contention for a database. Also, if you have specified optimized load mode (S2KLOAD) in the DBLOAD procedure, your input to that load cannot be a SYSTEM 2000 view descriptor for a database in the same environment.

When exclusive use of the database is not requested, the interface view engine uses SYSTEM 2000 record-level locking and multiple local holds. Basically, an observation is locked for retrieval and unlocked only when some other observation is retrieved or when the file is closed. Updates do not unlock the observation. This kind of locking could cause contention in a SYSTEM 2000 database. The interface view engine takes the following steps to keep the contention to a minimum:

At retrieval time, the engine attempts to lock all records in the path (with the PLEX /HOLD option). If the lowest level record in the path (that is, the deepest one, farthest from level 0) cannot be locked, an error return code is sent back to the SAS System, indicating that this observation cannot be locked. Records above the bottom level in the view will be locked if possible, but the engine does not regard it as an error when they cannot be locked, and no message is given to the user.
At update time, only those records that were successfully locked can be updated. For updates at levels that were not previously locked, the engine tries again to obtain the locks. If it cannot get them, the update fails, with a return code indicating that it could not get the necessary lock; partial updates are rolled back, assuming that rollback is enabled. If the engine gets the locks, it checks to see if the data in the database are still as they were when the data were originally retrieved; if they are the same, the update takes place.

The purpose of this locking mechanism is to avoid contention. You can always access a path as long as the bottom record can be locked. You will not have to wait for someone else to drop a lock on one of the upper level records. (However, there might be relatively few locks of upper level records.) You are guaranteed to be able to update only items in the record at the bottom of the view descriptor. The engine will tolerate attempts to update any level and will honor the update if it can.

Chapter Contents
Previous
Next
Top of Page