Erik Huelsmann wrote in a message to all:

 EH> Never before have I been programming using record locking. 
 EH> Everywhere I try to find info on it, the docs state that
 EH> unlocking should be done on the same region as locking, but
 EH> nowhere is stated that I can lock multiple regions.

Lock and unlock ranges must be exactly paired.  That is, you cannot unlock
part of a range which is locked and leave the rest locked.  If you need to
do this, you can use the atomic lock facility to do an unlock and lock as
an atomic operation.  All unlocks must be for the same range as was locked.

 EH> So: Can I lock multiple regions in one file? And if so, is 
 EH> there a way of telling how many regions I can lock within a 
 EH> file?

The maximum number of locks which can be simultaneously asserted is large.
You cannot assert locks which conflict with each other, and this is the
main restriction.  For example, you can assert DENY_WRITE locks on
overlapping regions, but you cannot assert DENY_ALL locks on overlapping
regions.  All the restrictions are explained in the documentation for
DosSetFileLocks() in the Control Program Reference.

 EH> And one more question: _When_ do I use file locking? I
 EH> suppose it is not necessary to lock a piece of a file each
 EH> time I access it, but what is secure? ie what is the minimum
 EH> safe situation when you have to lock a file? 

In some cases, you may need to lock a range whenever you access it.  You
need to lock a range if you need to guarantee consistency of file reading
and writing between multiple users.  In general, locks should be asserted
for each read and write operation, or across a group of read and write
operations, in any program where there is a realistic possibility that the
file will be modified by some other thread or process, either locally or
over a network.

 EH> The situation I am primarily interested in at the moment:
 EH> I have 2 apps running querying the same database. I know I
 EH> have to lock a record when changing its contents, but they
 EH> run extensive indexing routines. When I am querying through
 EH> the index, I do it in a recursively called routine. So on
 EH> return of the routine, the index might have changed, but in
 EH> the majority of cases it will not. Should I lock the
 EH> index-block with shared read access, lock completely, or
 EH> will this recursively calling and locking parts of the file
 EH> exceed the lockbuffers?

This depends mostly upon the type of index.  If you use a b-tree structure,
for example, then you need to lock the whole index whenever you modify it
in order to guarantee integrity.  In such a case, locking smaller regions
of the index file would leave open the possibility that the tree would be
traversed by one process while the other had modified part of the tree, and
this could lead to complete failure.

During the execution of a query, which by definition should not modify the
index, you can assert a DENY_WRITE lock only, and this will be safe and
have no peformance penalty as long as no need to modify the index file
arises. Many users can have DENY_WRITE locks asserted simultaneously, even
for overlapping regions or the whole file, with no problems.  If it becomes
necessary to modify the index file, then you will have to assert a DENY_ALL
lock and take the performance hit.

It is bad practice to assert locks recursively, and I cannot think of a
single case in which you would need to do this.  With a tree structured
index file, you are always going to have to lock the whole index file in
order to access it, so you might as well do that at the beginning and save
yourself trouble.

Assuming that you use any halfway reasonable index structure, you are going
to be recursing O(log(N)) times for N elements.  This means that you would
be hard pressed to have more than about 20 recursions and as many locks
asserted even when dealing with billions of records.
 
-- Mike


---