Next Previous Contents

8. Data access control

8.1 General

Since tables are regular UNIX files, I have so far found no need to implement, and have the associated overhead of, general data access controls in NoSQL. Setting the UNIX permissions on files or directory has proven very useful and effective. This is another example of how the NoSQL system works "with" UNIX, not in addition to it, e.g. not duplicating UNIX functions.

The Revision Control System (RCS) is one of the best configuration management tools available, it can be used for version control of many types of files, including tables. The operator 'nosql edit' will automatically check out a table for editing, and then check the new version back into RCS. Other operators can utilize tables that are under RCS control by using explicit commands like:

      co  -p  table | nosql row  ... | nosql column  ... | nosql print
    

or relying upon the 'cat' operator to handle interactions with RCS automatically:

      nosql cat table | nosql row  ... | nosql column  ... | nosql print
    

Note that this checks out a table, sends it to 'nosql row', then to 'nosql column', and finally prints the data with 'nosql print'. In general, any series of commands necessary can be constructed to do a given task even if the tables are checked into RCS.

8.2 Write concurrency control

When the 'nosql edit' operator is used (which modifies a table in place) there could be a possibility of silmultaneous writing of a table by multiple users. That is, if two or more users, on the same computer or perhaps on different computers on a network, attempted to modify a given table with 'nosql edit' at the same time, the table could become corrupted. To prevent this, write concurrency control is provided by the use of a lockfile, and is in effect whenever a user runs 'nosql edit' against the table.

The name of the lockfile is the name of the table being modified, with a suffix of ".LCK". For example a table named "main.rdb" would have a lockfile named "main.rdb.LCK". The lockfile is placed in the same directory as the table itself and is normally removed after the modification process is complete, even if the operation is aborted with an INTERRUPT signal (CONTROL-C or <DEL>). However in the event of an emergency such as a computer system crash the lockfile could be left in place, preventing the use of 'nosql edit' against the same table when the computer system is again operable. When an attempt to use this utility is made and there is an existing lockfile associated with the referenced table an online message is produced and the operator dies. In this case simply remove the lockfile with the UNIX command 'rm' and proceed. If an emergency has not occurred appropriate caution should be exercised before removing a lockfile, due to the possibility of data corruption.

An shell variable related to locking is NSQLOCKER; it designates an external locking program to be used in place of the lock shell script provided by NoSQL. An excellent locking program is the lockfile utility, normally distributed with procmail (a mail filtering system), which usage is recommended over the simple NoSQL built-in 'lock' utility. NSQLOCKER, if set, must contain any extra arguments needed by the locking program, e.g. NSQLOCKER="lockfile -r1". NoSQL will automatically use NSQLOCKER if set, otherwise it will fall-back to using its builtin 'lock' script.


Next Previous Contents