1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Draft//EN">
<HTML>
<HEAD>
<TITLE>NoSQL: Data access control</TITLE>
</HEAD>
<BODY>
<A HREF="NoSQL-6.html">Previous</A>
<A HREF="NoSQL-8.html">Next</A>
<A HREF="NoSQL.html#toc7">Contents</A>
<HR>
<H2><A NAME="s7">7. Data access control</A> </H2>
<H2><A NAME="ss7.1">7.1 General</A>
</H2>
<P>Since rdbtables are regular UNIX files, we 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.
<P>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
rdbtables. The operator 'nsq-ed' will automatically check
out an rdbtable for editing, and then check the new version
back into RCS. Other operators can utilize rdbtables
that are under RCS control by using commands like:
<P>
<BLOCKQUOTE><CODE>
<PRE>
co -p table | nsq-row ... | nsq-col ... | nsq-pr
</PRE>
</CODE></BLOCKQUOTE>
<P>Note that this checks out an rdbtable, sends it to
'nsq-row', then to 'nsq-col', and finally prints the data
with 'nsq-pr'. In general, any series of commands
necessary can be constructed to do a given task even
if the rdbtables are checked into RCS.
<P>
<H2><A NAME="ss7.2">7.2 Write concurrency control</A>
</H2>
<P>When either of the two utility operators 'nsq-ed' or
'nsq-tee' is used (which modify an rdbtable in place)
there could be a possibility of silmultaneous wrting of an
rdbtable 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 rdbtable with either
'nsq-ed' or 'nsq-tee' at the same time, the rdbtable could
become corrupted. To prevent this, write concurrency
control is provided by the use of a lockfile, and is in
effect when either of the two utility operators is used.
<P>The name of the lockfile is the name of the rdbtable
being modified with a suffix of ".LCK". For example an
rdbtable named "main.rdb" would have a lockfile named
"main.rdb.LCK". The lockfile is placed in the same
directory as the rdbtable 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 'nsq-ed' or 'nsq-tee' when the
computer system is again operable. When an attempt to use
either utility operator is made and there is an existing
lockfile associated with the referenced rdbtable 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. To overcome this
problem, NoSQL honours the environment variable NSQLOCKS.
If set, this variable instructs NoSQL to use a centralized
directory for creating the lock files. It is then quite
easy to set up an automated procedure that cleans up that
directory at machine boot time.
<P>A related environment variable is NSQLOCKER; it designates
an external locking program to be used in place of the <EM>nsq-lock</EM> shell script provided by NoSQL.
A very good locking program is the <EM>lockfile</EM> utlility,
normally distributed with <EM>procmail</EM> (a mail filtering
system), which usage is recommended over the trivial nsq-lock
utility. NSQLOCKER, if set, must contain any extra arguments
needed by the locking program, e.g. NSQLOCKER="lockfile -r1".
Currently only <EM>nsq-tee</EM> honours NSQLOCKER, while the
other NoSQL utilities that need file locking handle it internally
(i.e. they do not even use nsq-lock).
<P>
<HR>
<A HREF="NoSQL-6.html">Previous</A>
<A HREF="NoSQL-8.html">Next</A>
<A HREF="NoSQL.html#toc7">Contents</A>
</BODY>
</HTML>
|
