Clipper locking and Novell
Quote:
>I just came from a telecon with my client and novell tech staff.
>Novell has a major problem with the clipper locking mechanism (ie. the
>huge offset added to lock requests) - they claim it may cause problems.
>It seems that 5 of the 15 site of my client experience problems (novell
>3.12 or 4.11, and client 32 2.2 and/or 3.0), and Novell blames clipper.
IMHO, Novell is right, since it is Clipper behaviour to lock
associated index file when the pointer is wandering through the dbf
file (ie. skip, goto, gotop, seek etc)
Quote:
>Some sites with the same config are problem free, without any
>consistency!
Probably they are rarely using the same file at the same time.
Quote:
>The problem is commonly a "client 32 error", disconnected from the
>server.
>In the worst scenario (unrelated to the offset), something locked an
>index open, and the internal lock of dbskip() on another workstation was
>banging the network for 17 seconds "as fast as the network would go".
>It was suggested by Novell that at some point they may prevent such lock
>requests (ie. outside the file size)!
Right solution IMHO. But Clipper with 3rd library can also do this.
My real experience :
1) Schedule the "append" jobs on specific time. Say, every 2 hours or
whatsoever. So, during the non append time, every new records will
be stored in temporary files. During that time, we could disable
the locking "feature" of Clipper. DBF travelling will be somewhat
10x (even more) faster then.
2) The following is a logic explanation from SIx3 NG file :
What is TURBOREAD?:
Did you know that Clipper automatically puts a file lock on your
index file when you do any record pointer movement (SEEKs, SKIPs,
etc...) on a network? This means that anyone else on the network
has to wait for your SEEK to finish before they can do a SEEK...or
a record update...or an append...or a delete. Needless to say, this
can cause quite a bit of slowing on a large database with a lot of
users.
By using the SIx Driver's SET TURBOREAD ON command, you turn off
Clipper's forced index locking, allowing your application to run
faster. However, if you turn off the index locking, this means that
if somebody does an update during your SEEK, it may throw the record
pointers off. Your SEEK may point to the wrong record! So, you may
be wondering when and how to use SET TURBOREAD ON safely. Here are
some situations:
* On some large systems, network users input their new data into
temporary database files. Then, batch updates are done on the
primary database files at night, appending the new data from the
temporary files. During the day, the network users would only
be accessing the primary database files for queries and reports,
but no direct updates.
In this case, during the day, you can SET TURBOREAD ON without a
care. Since you know that nobody will be performing updates,
there is no reason at all to lock the index files.
* In cases where network users are doing updates directly on the
primary database, you could use the SIx Driver's
semaphore-locking functions to prevent index corruption.
Take a look at the descriptions in the SIx Driver Functions
section on the following semaphore-related functions:
Sx_MakeSem() - Creates a semaphore file
Sx_IsSem() - Checks for the existence of a semaphore file
Sx_KillSem() - Deletes a semaphore file
Network users that want fast access to the database and indexes
should call Sx_MakeSem() to signal that no updates should be
done. Then SET TURBOREAD ON and blaze through the file. When
done, SET TURBOREAD OFF and call Sx_KillSem() to allow other
users to update the index.
WARNING: As a general rule, NO updating should be done on a network
with with SET TURBOREAD ON. This is extremely risky, and
could result in index and/or data corruption.
Quote:
>Obviously, this suggestion by Novell would break any xbase DBMS (even
>products such as CodeBase - which is Clipper-compatible).
>Does this ring a bell? Opinions? Anything?
>Sent via Deja.com http://www.deja.com/
>Before you buy.
--
Andi Jahja <see headers for my e-address>
