Opportunistic locks are incredibly useful when it comes to clients synchronising their files for caching across a network, it allows anybody to place a lock (more so known as an oplock) on any files that are residing on a server. The main reason this whole process is existent is because it allows for the data to cache locally, which improves on the all around response time of your server (as well as manages network traffic, keeping it more open for your users). The main reason oplocks are used is because network re-directors have found a use for them within clients remote servers (including some client applications that may be on any local servers).
The locks themselves make sure that clients data caching and coherency work perfectly in every sense, it’s essentially made to work with multiple clients at once. To make it a lot more simple, if the data is proper, then the data on the servers (as well as amongst all the clients) is in proper order (known as synchronized). Every single file that requests an oplock has to go through a requesting process, as well as being opened for an asynchronous operation. Be aware that these locks aren’t commands by the client that are getting fed to the server, their actually requests from the client to the server itself. Many clients find the whole process quite appealing, the server allows for these locks whenever the circumstances are right
Whenever an application that is stored on a local server is requesting access to a remote file on the server, oplocks aren’t necessarily “seen” by the application itself. It’s the network re directors protocol (as well as the servers) to open and close the locks accordingly. Remember, local applications shouldn’t request any oplocks from remote servers, as all it will do is return an error message. Oplocks themselves have a very limited range of things they can accomplish, they are usually used to test the quality of a network re-director or a server opportunistic lock handler.
There are three main types of oplock, which I will cover in more detail in my next article on the subject, but in brief they are; Batch Locks, Exclusive Locks and Level 2 Locks. Batch Locks originally were designed to cope with the mechanism by which MS-DOS based batch script files repeatedly open, read/write and then close the same file in a short space of time and improves execution speed by providing a high speed cache.
There are terms that people may not be completely aware about when it comes to the management of oplocks, things like the “coherency of data” can be confusing to some. Seeing as the locks themselves only provide a small amount of benefit to servers, it’s still better than nothing. It’s possible to minimize the amount of “damage” your application will have on the clients using it, as well as the impact the clients actually have on your application itself. This is possible by allowing them to share data as much as they possibly can. This minimizes the amounts of access levels you need on your server in the process, which of course allows for more flexibility in a sense.