OpLocks, or opportunistic locks, are a way to cache file data at the client. This allows the client to read and write data using its local cache and interact with the file server only when necessary. OpLocks are acquired after a normal NCP file handle has been obtained. OpLocks should help both client and network performance by reducing the amount of traffic on the network.
When a server requires a client to release its oplock, it sends it a tickle packet. Tickle packets are very similar to broadcast packets. The main difference is that they include a dollar sign ($) character instead of an exclamation point (!) character for the control information. Tickle packets also contain the file handle, so the client knows which oplock to release.
There are two types of OpLocks: L1 (level 1) and L2 (level 2). You can set OpLocks to either of these levels or disable OpLocks completely. By default, OpLocks is set to level 2, which includes both level 1 and level 2 functionality.
WARNING:Level 2 OpLocks are inappropriate for server-side database applications: Do not use OpLock Level 2 with databases. Level 1 OpLocks can remain switched on.
L2 OpLocks give the client shared read access to the file. Multiple clients can have L2 OpLocks for the same file. Not all clients accessing the same shared file require L2 OpLocks; some might not have an oplock at all. The L2 oplock entitles the client to cache file data locally for reads, but not for writes. This is useful when the client reads the same data over and over. L2 OpLocks should be released when the client application closes a file, because the server won’t notify the client when another connection wants exclusive access to that file (delete, rename, exclusive open, etc.).
When a client writes to a file that has L2 OpLocks for other clients, all the other clients are sent a tickle packet to notify them that their local cache for that file is no longer valid. When the client receives this tickle packet, it does the following:
Acknowledges the tickle packet.
Invalidates its local cache for the file.
Clears its oplock for the file.
The server does not grant an L2 oplock for a file that has been written to recently by a client other than the one requesting the lock.
L1 OpLocks give the client exclusive access to the file. The client can cache reads and writes locally. The client can even close the file without notifying the server; this is useful for when the client application opens and closes the same file over and over.
L1 OpLocks can be acquired by using NCP to open the file and then setting the corresponding oplock request bits. If another connection has the file open, the L1 oplock is denied—you cannot get an oplock on a file that is currently shared with another client.
If another connection tries to access (open, rename, or delete) an L1 oplocked file, the owner of the oplock is notified with a tickle packet that the lock needs to be broken. The client then does the following:
Acknowledges the tickle packet. For protocols like IPX and UDP, this lets the server know that the client received the tickle packet.
Flushes any dirty cache buffers to the server.
Acquires any cached physical record locks if it plans on keeping the file open.
Performs one of the following four operations:
Clears the oplock.
Refuses to clear the oplock.
The Novell Client never does this.
Downgrades the oplock to an L2 shared lock.
Closes the file.
With all L1 OpLocks, the server waits for the client holding the L1 oplock to respond before allowing the new access request to continue. Because NCP allows only one outstanding request for a client connection, the server must be careful never to send a tickle packet to the client making the initial access request.This avoids a deadlock situation.
Oplock support can be turned off or on at the client or at the server. The server lets the user enable only L1 OpLocks or both L1 and L2 OpLocks.
OpLocks are automatically released when a file is closed.
A client can’t open, rename, or delete a file while another client has an L1 oplock on it. The request causes a tickle packet to be sent to the client holding the oplock; the server then waits for a reply from that client and then continues based on the client’s response.
When a client has an L1 oplock for a file, it doesn’t need to send physical record lock requests to the server for that file. It can track the locks locally. If the client later needs to release the oplock, it needs to acquire any outstanding physical record locks from the server before continuing. For L2 OpLocks, physical record locks should be managed at the server instead of the client to avoid deadlocks.
If a client tries to open, rename, or delete a file that it already has L1 oplocked, the open fails because the server cannot delay the request and wait for notification from the client that it has cleared the oplock.