Information on Opportunistic Locking

Opportunistic Locking Enabled
Opportunistic Locking Disabled
Poor or Slow LAN/WAN Performance
Files do not open
Files do not save
Problems with Word, Excel, Access and other Microsoft Applications
Problems with Database Applications
Corrupt database
Problems with applications that use temporary, temp or tmp files
Server hangs
Slow server
Slow client
Slow network
Station xx (task X) timed out waiting for an op-lock on file xxxxxxxx.xxx held by station xx
Information on Opportunistic Locking

This fix has multiple components.  All of them must be implemented:

• Server

Minimum NW65SP7

SET CLIENT FILE CACHING ENABLED=ON

SET LEVEL 2 OPLOCKS ENABLED=ON (unless a server-side database application is in use*)

• Client

Minimum Novell Client 4.91 SP4

Client Properties -> Advanced Settings -> Parameter Group=Performance, Cache -> File Caching=ON

* Opportunistic Locking is a Client/Server technology so this refers to databases held on the server but accessed by multiple clients; e.g. Microsoft Access.  Server databases that are not accessed directly by clients are not affected.  If in doubt contact the supplier of the database.

What are OpLocks?  What is Opportunistic Locking?

Opportunistic Locking is a method of caching server data locally on the client.  This can result in significant performance improvements.

Note that Novell's Opportunistic Locking is based on Microsoft's original specification.  Some issues may be due to that design and out of Novell's control. 

Level I OpLocking allows a single client to effectively read in an entire file, keep a copy on the workstation and lock the version on the server.

Level II OpLocking allows multiple clients to read in the same file, keep a copy on the workstation and share the version on the server. 

OpLocks should not be confused with any of the following:

• File Locks:  lock the file on the server but don't cache it locally
• Record Locks:  as used by back-end database applications
• Byte range Locks:  also used by back-end database applications; client requests to lock 128 bytes at offset A1000, etc

How is it possible to tell if a database is using record or byte locks?  The only reliable way is to trace it (look for NCP 87,32).

What are the Pros and Cons of Opportunistic Locking?

• No OpLocking
  Reliable
  Slow - does small reads (small reads are the lowest common denominator - if the application isn't optimised to request request big reads then the client will go with the safe option rather than negotiate a large read).
• Level I
  Fast - does big bursty reads
  Caches file locally and puts an exclusive lock on the server version
  Can cause slowness
  Can cause server hangs
• Level II
  Fast
  Caches file locally but lets other clients cache locally, too
  Can cause Database corruption
  Can cause failure to save

Further Information on Opportunistic Locking

OpLocking is more complicated than it initially seems.  This section summarizes what is going on behind the scenes.

• Level I

If Client1 holds an OpLock I and then Client2 wants the file, the server will BROADCAST a request to clear OpLocks so that Client2 can obtain the lock.

Client1 then has to ACK this broadcast.  Once it has done that, it can choose whether to close the file (so that Client2 can have it) or switch to Level II OpLocking (so that they both can have it).

Here lies a potential problem:  Client1 has to ACK the server's broadcast.  If Client1 does not ACK then Client2 is going to wait.  Consider what could happen if Client1 and Client2 are on separate subnets or VLANS or if Client1 sits on a flaky network. 

Now consider how this issue would be traced.  What benefit is a trace of Client2, where we only see the symptoms?  This problem must be traced at the server.

• Level II

A Level II OpLock allows multiple clients all to cache a copy of a file locally.  This can be very effective as long as the client is only reading a file.

When a client wants to do a write, the system operates on a first-come first-served basis.  When this happens the server does a broadcast and expects all the clients to ACK it, but it won't wait, and will grant the writer exclusive access and assume that everyone else will clear their cache and get the new just-written version.

Therefore, if Writer2 doesn't see the initial broadcast then the save may fail or, if a database application is involved, the database could become corrupt (as the data is never successfully written).

Problems with applications that use temp files (e.g. Word, Excel etc)

With applications that use temp files, the sequence of events should be:

1 Client Opens Original >

2 Client Creates Temp (copy of original) >

3 Client Modifies Temp >

4 Client Saves Temp >

5 Client Deletes Original >

6 Client Renames Temp to Original's Name

Then we go back to Step 2, etc, without having closed the file.

Some versions of the client occasionally miss out Step 5.  Obviously this causes problems, as Step 6 (and thus the save) will fail.  This may also generate the console error "Station xx (task X) timed out waiting for an op-lock on file xxxxxxxx.xxx held by station xx"

This is fixed in Novell Client 4.9 SP2 + the latest 4.9 Post-SP2 NWFS.SYS (49psp2_nwfs_8.exe) and later.

OpLocking and NCPs

The Novell client implements OpLocking through NCP (87,32).  Originally when the Novell client needed to open a file it would issue an NCP 87,01 (Open/Create file or subdirectory).  Novell modified the 87,01 NCP to include a flag (OCCRetFlag) to request an op-lock.  The new NCP 87,32 (Open/Create file or subdirectory with Callback) utilises the same structure as NCP 87,01 but also includes this new flag.  When clients are configured to support OpLocking/File Caching then open requests are performed with the 87,32 NCP.

Summary

• When troubleshooting poor performance, turn OpLocking ON as a diagnostic
• When troubleshooting file open/save problems, turn OpLocking OFF as a diagnostic
• Take traces at the server and do not filter traces (OpLocking uses broadcasts and then expects ACKs from other clients, so just trace everything and filter within the trace analyzer)
• There are problems with applications that use temporary files, so look for file renames and file deletes in traces, especially those that result in an error
• A lack of response to a broadcast can cause issues so look for broadcasts - the server will broadcast a Clear Callback and the client should ACK Callback
• Failure to ACK the Clear OpLock Broadcast is an issue inherent in the technology
• Level II OpLocks may be inappropriate for database applications:  don't use OpLock Level II with databases (Level I OpLocks can remain switched on, however)

OpLocking issues with older versions of NSS and Novell Client are well documented.  As of NW65SP7 and Client 4.91SP4 there are no known outstanding issues with OpLocking reported to Novell.  Refer to the client README https://www.novell.com/support/search.do?searchString=client+4.91+for+windows+readme for details of the latest issues fixed.

Further resources

These links are provided as a courtesy.  Novell is not responsible for, and does not endorse in any way, the content of external internet sites.

http://support.microsoft.com/default.aspx?scid=kb;en-us;129202 - Microsoft QID article

http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html - 3rd Party White Paper

http://www.superbase.com/services_tech_support_oplocks.htm - 3rd Party paper on Opportunistic Locking in a pure Windows environment

https://support.microfocus.com/kb/doc.php?id=10085899 - Further information on Novell's implementation of OpLocking

Formerly known as TID# 10095627

Updated Note in the Internal Section to reference updated TID number 3198612. - Earle Wells, 28Jan2010

+ Upgrading to Open Enterprise Server 2 SP1 Linux

+ Open Enterprise Server 2 SP1 Migration Strategies