[ Back | Print ]
Technical Information Document
Information on Opportunistic Locking - TID10095627 (last modified 26APR2005)
printer friendly tell a friend
Click here if this does not solve your problem

Information on Opportunistic Locking


Novell Operating Systems

Novell Clients

Opportunistic Locking aka OpLock aka OpLocking aka Op Lock aka Op-Lock aka Op-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


Opportunistic Locking incorrectly implemented


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

  • Server

Minimum NW6SP5/NW65SP2


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

  • Client

Minimum Novell Client 4.9 SP2

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



OpLocking is a Microsoft invention.  See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/opportunistic_locks.asp for more information.  (This link is provided as a courtesy.  Novell is not responsible for, and does not endorse in any way, the content of external internet sites.)

This TID discusses Novell's implementation of Opportunistic Locking.

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.

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.

What are the Pros and Cons of Opportunistic Locking?

  • No OpLocking
    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
    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 summarises 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.  This is not a bug in Novell's implementation - this is a problem inherent in the design of OpLocking.

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.


  • 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 are 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 NW6SP5/NW65SP2 and Client 4.9SP2 there are no outstanding issues with OpLocking reported to Novell other than the Temp file issue, mentioned above.

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://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/opportunistic_locks.asp - Microsoft MSDN article

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

http://support.novell.com/cgi-bin/search/searchtid.cgi?/10085899.htm - Further information on Novell's implementation of OpLocking

Document Title: Information on Opportunistic Locking
Document ID: 10095627
Solution ID: NOVL99930
Creation Date: 30NOV2004
Modified Date: 26APR2005
Novell Product Class: Netware


The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.

Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.

[ Back | Print ]