In other words, oplocks are introduced to synchronize the data in an environment of multiple workstations, each of which having their own local cache, sharing a file via a file-server. Imagine a situation where 2 workstations read data into their local cache and a single workstation writes data back.
With oplocks the local cache of workstation 2 gets informed about the fact of modification by other workstations and therefore invalidates its local cache. In practice the oplocks introduced by Microsoft are good enough when it comes to sharing files like Word documents or Excel spreadsheets in a networking environment.
The reason for the problems the oplock approach has with file based database systems lies in their specific characteristic how they deal with the file-system. File based database systems:. Since Windows NT 4. At best your network performance is sluggish, at worst you encounter problems with an open file shared by the LAN Manager such as:.
You can find various MS Knowledgebase articles about this issue. However, understanding the Microsoft terminology is critical here:.
Q Explanation of Opportunistic Locking on Windows NT This article describes additional configuration parameters regarding oplocks. This article describes how to detect if the problem is related to oplocks and the CachedOpenLimit configuration parameter.
You are not alone! The simplest way to resolve problems related to oplocks is to disable them on behalf of the LAN Manager server. Oplocks are a significant performance enhancement, but have the potential to cause lost cached data on some networks, particularly wide-area networks. We have not encountered any performance drawbacks in real-world scenarios after having disabled oplocks.
For example, a client may not have to write information into a file on a remote server if the client knows that no other process is accessing the data. Likewise, the client may buffer read-ahead data from the remote file if the client knows that no other process is writing data to the remote file.
Applications and drivers can also use oplocks to transparently access files without affecting other applications that might need to use those files. File systems like NTFS support multiple data streams per file. Oplocks are granted on stream handles, meaning that the operations apply to the given open stream of a file and, in general, operations on one stream do not affect oplocks on a different stream.
There are exceptions to this, which are explicitly listed below. For file systems that do not support alternate data streams, such as FAT, think of "file" when this document refers to "stream". A Level 2 or shared oplock indicates that there are multiple readers of a stream and no writers.
This supports client read caching. A Level 1 or exclusive oplock allows a client to open a stream for exclusive access and allows the client to perform arbitrary buffering.
This supports client read caching and write caching. A Batch oplock also exclusive allows a client to keep a stream open on the server even though the local accessor on the client machine has closed the stream. This supports scenarios where the client needs to repeatedly open and close the same file, such as during batch script execution.
This supports client read caching, write caching, and handle caching. A Filter oplock also exclusive allows applications and file system filters including minifilters , which open and read stream data, a way to "back out" when other applications, clients, or both try to access the same stream.
A Read R oplock shared indicates that there are multiple readers of a stream and no writers. A Read-Handle RH oplock shared indicates that there are multiple readers of a stream, no writers, and that a client can keep a stream open on the server even though the local accessor on the client machine has closed the stream.
This supports client read caching and handle caching. From the point of view of the client, they are opportunistic. In other words, the server grants such locks whenever other factors make the locks possible. When a local application requests access to a remote file, the implementation of opportunistic locks is transparent to the application.
The network redirector and the server involved open and close the opportunistic locks automatically. However, opportunistic locks can also be used when a local application requests access to a local file, and access by other applications and processes must be delegated to prevent corruption of the file.
In this case, the local application directly requests an opportunistic lock from the local file system and caches the file locally. When used in this way, the opportunistic lock is effectively a semaphore managed by the local server, and is mainly used for the purposes of data coherency in the file and file access notification.
Before using opportunistic locks in your application, you should be familiar with the file access and sharing modes described in Creating and Opening Files. The maximum number of concurrent opportunistic locks that you can create is limited only by the amount of available memory. Local applications should not attempt to request opportunistic locks from remote servers. An error will be returned by DeviceIoControl if an attempt is made to do this.
Opportunistic locks are of very limited use for applications. The only practical use is to test a network redirector or a server opportunistic lock handler. Typically, file systems implement support for opportunistic locks. Applications generally leave opportunistic lock management to the file system drivers. Skip to main content.
0コメント