How VFP record locking can work

[TCmullet]

thread184-213744

The above thread came up when I Google-searched my question "how is vfp record locking implemented", but it's locked, so I can't piggyback directly, and it didn't answer my question.

I don't really have a "server", but have several stations and the data is on one of them. Obviously, VFPOLEDB is running on each one, but I don't see how they can talk to each other.

If I lock a record from one station, how can some other station have a failed lock attempt on that record, that is, how can IT know that the 1st station has it locked? For simplicity, say all PCs are WinXP. Is there some invisible entity on the hosting XP that manages everyone who might be trying to lock a record?

The corollary question to this is, lets say I have a record locked for awhile. Then 3 other stations start waiting to lock that record. ("set reprocess to 0, x=rlock()") Will the XP station that is hosting the file somehow allow one of the other 3 stations *and only one* to get their lock without causing any kind of hiccup to the remaining stations waiting? Will the lock successes be handed out in first-come first-serve fashion til all have each had their own successful lock?

I'm having a hard time grasping how VFPOLEDB running on all can talk to each other at all, and not have the scenario where when 1st lock is released, two waiting ones are tied for getting in, but only gets in and the other crashes instead being forced to wait.

Some of this is very hard to test, therefore I'm asking you experts.

(Btw, I'm writing in C#.net 2008, not native VFP.)

 

[Mike Lewis]

Hi TCMullet,

First, welcome to the forum. There are some very knowledgeable people here who can answer your questions better than I can, but I'll take a shot at it anyway.

Is there some invisible entity on the hosting XP that manages everyone who might be trying to lock a record?

Yes: the operating system. File and record locking in VFP is not so very different from most other environments. It's the OS that manages the locks. It doesn't know or care where the lock requests are coming from.

Will the XP station that is hosting the file somehow allow one of the other 3 stations *and only one* to get their lock without causing any kind of hiccup to the remaining stations waiting?

Yes. In the scenario you described, each station will re-issue its lock request indefinitely, or until the request is granted. Once the existing lock is released, the OS will grant a new lock to whichever request comes in next (in other words, it's first come, first served). And so on until all the requests have been served.

I hope this is of some help. As I said before, you will probably get some more detailed answers from the other regulars. In the meantime, if any of the above needs clarifying, just shout.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Mike has pinpinted it already: It's the OS, or the file system that manages the locks, there is no need for a server to manage this, on client OSes the same file systems are used and the same protocols (SMB), that's not part of a server only. And it's not the OLEDB provider locally remembering what it locked, that wouldn't have any effect on other clients, would it?

This is the secret of enabling locking and transactions without any server component, which would serialise and queue all requests and handle them centrally, the organisation of locks is maintained by the OS and files system, so there does not need to be a central active server component. The central component is the OS. VFPs Lock machansism works on FAT and NTFS and even on linux file systems, as long as they are windows enabled via SAMBA, which emulates the SMB protocol towards windows clients, so the central "thing" is SMB.

It's a low level SMB command to lock a file or some bytes of it. Eg look here

http://timothydevans.me.uk/nbf2cifs/smb-smbcommandcode.html

SMBlock and SMBunlock.

And the locks are maintained by the OS, also client OSes. File shares are not an exclusive feature of server OSes, so your Workgroup network without a server is enough to support the VFP locking.

Actually it's nevertheless recommendable to introduce a real server, people using such network layouts without a server more often hve problems with VFPs locking mechanism.

I make the impression to know all the details perhaps but even if I know more than Mike in that repsect, I also don't know it all. You can use network sniffers (eg Wireshark) to record SMB commands and analyse what VFP really does, so you could find out more about it.

And so, yes Rick Beans answer was surely also correct already, the OSes are maintaining the locks.

Bye, Olaf.