Clipper locking and Novell 
Author Message
 Clipper locking and Novell

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.

Some sites with the same config are problem free, without any
consistency!

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)!

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.*-*-*.com/
Before you buy.



Mon, 01 Jul 2002 03:00:00 GMT  
 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>


Wed, 03 Jul 2002 03:00:00 GMT  
 Clipper locking and Novell
The best way to saturate a NOVELL server with locks ... is to forget to
dbunlock() ... Should help!
Bye, Jean-Pierre.


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.

> Some sites with the same config are problem free, without any
> consistency!

> 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)!

> 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.



Wed, 03 Jul 2002 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Clipper Table Locking, Novell and Foxpro

2. Novell locks under Clipper

3. Novell / Clipper Locking

4. Clipper locking files open on Novell 3.11

5. Clipper 5.2e, Clipper Tools and Novell 5 ???

6. Lock Error 81, Novell Client32

7. Is Opportunistic locking a prob on Novell?

8. Lock Failure with Novell 4.11

9. NT 4 w.station client and novell 3.12 lock failure 1035

10. Who's locked novell file?

11. Novell File Locking

12. Locking problems on novell 3.11

 

 
Powered by phpBB® Forum Software