Hi,

Is the OpLocks setting relevant to the workgroup (non c/server) version of Pervasive?

I am aware that with some db's such as Access and Foxpro having OpLocks enabled can cause corruption where as other newer db's need it enabled in order to run fast.

I am not sure if Pervasive with it Microkernel engine makes any use of this setting at all, and if so which way it needs to be.

Many Thanks
Mark

What OpLocks setting?

Oportunistic Locking described below, it causes corruption in many non-server databases including Access, FoxPro, Paradox, etc.
Disabling it via the registry prevents the problems but can cause other db's to run quite slow.


With Exclusive Oplock, if a file is opened in a non-exclusive (deny none) mode, the redirector requests an opportunistic lock of the entire file. As long as no other process has the file open, the server will grant this oplock, giving the redirector exclusive access to the specified file. This will allow the redirector to perform read-ahead, write-behind, and lock caching, as long as no other process tries to open the file.

When a second process attempts to open the file, the original owner will be asked to Break Oplock or Break to Level II Oplock. At that point, the redirector must invalidate cached data, flush writes and locks, and release the oplock, or close the file.

Opportunistic Locking level II, provides a method for granting read access to a file by more than one workstation, and these workstations can cache read data locally (read-ahead). As long as no station writes to the file, multiple stations can have the file open with level II oplock.
Back to the top

MORE INFORMATION
An illustration of how level II oplocks work:

1. Station 1 opens the file, requesting oplock.
2. Since no other station has the file open, the server grants station 1 exclusive oplock.
3. Station 2 opens the file, requesting oplock.
4. Since station 1 has not yet written to the file, the server asks station 1 to Break to Level II Oplock.
5. Station 1 complies by flushing locally buffered lock information to the server.
6. Station 1 informs the server that it has Broken to Level II Oplock (alternatively, station 1 could have closed the file).
7. The server responds to station 2's open request, granting it level II oplock. Other stations can likewise open the file and obtain level II oplock.
8. Station 2 (or any station that has the file open) sends a write request SMB. The server returns the write response.
9. The server asks all stations that have the file open to Break to None, meaning no station holds any oplock on the file. Because the workstations can have no cached writes or locks at this point, they need not respond to the break-to-none advisory; all they need do is invalidate locally cashed read-ahead data.


regards
Mark

Well, there's no setting for OpLocks in Pervasive/Btrieve. Pervasive/Btrieve can use both OpLocks and Pessimistic Locks. The developer determines which lock method is used.
Are you using the Btrieve or ODBC/Relational interface?

Hi mirtheil,

We are using the Btrieve Interace (api).

My guess is that the OpLocks setting is irrelevant as the Microkernel manages all these types of requests in a proprietry type of way.

I think if OpLocks caused as much of a problem for Pervasive as its does with Access etc then you would have known about, so I don't think it should be an issue.

Many thanks for your speedy replies.

Kind Regards
Mark

You might want to check out the folloiwng as a start on Pervasive locking:
http://www.pervasive.com/library/doc..._gde-12-3.html
It's marked as for 9.1, but the Btrieve API is the same as previous versions.

Thanks for that, much appreciated I'll take a read later.