Record Locking

[Brian K. White]

On 4/19/21 11:12 AM, Nancy Palmquist via Filepro-list wrote:
>
>> E. Lookup processing that locks but does not release record
> I see this often on Windows Server versions and the only way to 
> release this is to reboot windows.  On a project where the data entry 
> is done from a dummy file, it is obvious when locks are stuck that it 
> came from lookups.  I am of the opinion that filepro is too fast for 
> Windows Server systems.  I will often have to put in sleep commands to 
> give Windows time to update data and remove record locks before I 
> continue.  It is a shame but it saves quite a bit of problems in the 
> long run.
>
> I have seen invoice numbers that need to be generated sequentially, 
> and when 2 users are pulling numbers, it will get duplicates even when 
> the record is opened with a lock and written when updated to release 
> the locks.  Somehow both users are able to get the same number.  My 
> conclusion is that the lock was not seen by the second user, who was 
> able to access the record before the lock was applied.  Even though 
> the lock command was sent before the data was pulled.  I had to invent 
> a workaround for this to insure it never happened, but it should have 
> worked without that being necessary.

That is a stunner.

That is out and out full-on failure of the host OS on client or server 
or both, or the shared-drive protocol between clients and server. To me, 
that is such a fundamental failure that I couldn't possibly live with 
solving it by sleep(). I'd have to hunt down what is actually failing 
(like, maybe some locking or caching tunable setting in the shared drive 
server or client), or not use that component or platform at all. I mean 
all bets are off in that case. If it's physivcally possible even once, 
for two different clients to claim the same exclusive write access to 
the same block of disk or file, then that is simply broken. Not 
imperfect or less than ideal, but unusably broken. Anything could happen 
and sleep() is merely making it less likely, not actually fixing it. And 
you couldn't really ever trust anything else. Every random report that 
generates totals, you couldn't trust the numbers. It's insane.

-- 
bkw