"File is in use" - but I have a record lock!

I got this error from one of my users. In the code below I am applying
manual record locks, and I would assume that it would protect the code from
another user attempting a header lock but they got a "File is in use" on the
gather memo...
This runs in a high speed environment and I cannot rely on the default
Foxpro locking mechanisms.
Should I apply another test prior to writing the values back to the table,
and what would that test be if rlock() was already succesful?

nLock = 0
do while nLock < 100
if rlock()
nLock = 0
exit
else
sleep(50 + int(rand() * 100))
nLock = nLock + 1
endif
enddo
if nLock = 0
scatter memo name oTrack
* .... do stuff with the variables
* got a "file is in use.." error even though rlock() had been applied.
gather memo name oTrack
Unlock
endif

man-wai
Tue Dec 06 20:24:45 CST 2005

> nLock = 0
> do while nLock < 100
> if rlock()
> nLock = 0
> exit
> else
> sleep(50 + int(rand() * 100))
> nLock = nLock + 1
> endif
> enddo

You don't need your wait routine if you must get the rlock(), do you? I
see no abort mechanism if rlock() fails.... you could use:

SET REPROCESS TO 30 SECONDS
select cTable
go nRecordNo
if rlock()
do stuff
else
messagebox("Record in use. Try again later!")
endif

> if nLock = 0
> scatter memo name oTrack
> * .... do stuff with the variables
> * got a "file is in use.." error even though rlock() had been applied.

Did you move the record pointer after the SCATTER in your "stuff"? Did
you SELECT another alias?

> gather memo name oTrack
> Unlock
> endif
>
>


--
.~. Might, Courage, Vision. Sincerity. http://www.linux-sxs.org
/ v \
/( _ )\ (Fedora Core 4) Linux 2.6.14-1.1644_FC4
^ ^ 10:20:01 up 6 days 21:56 load average: 0.00 0.00 0.00

Paul
Tue Dec 06 22:06:40 CST 2005

I don't want to use the default locking mechanisms, this code is called
recursively and often, in database triggers.

> You don't need your wait routine if you must get the rlock(), do you? I
> see no abort mechanism if rlock() fails.... you could use:
The wait routine is there to allow other processes time to complete, it is
randomized to minimize lock contentions. The abort mechanism is there, the
loop fails after 100 attempts.

> Did you move the record pointer after the SCATTER in your "stuff"? Did
> you SELECT another alias?
There is no record movement or selecting of tables

man-wai
Tue Dec 06 23:58:43 CST 2005

>> Did you move the record pointer after the SCATTER in your "stuff"? Did
>> you SELECT another alias?
> There is no record movement or selecting of tables

I supposed there is no UNLOCK in the "stuff"?

Wonder what the "stuff" is doing... The problem should be inside the stuff.

--
.~. Might, Courage, Vision. Sincerity. http://www.linux-sxs.org
/ v \
/( _ )\ (Fedora Core 4) Linux 2.6.14-1.1644_FC4
^ ^ 13:57:01 up 7 days 1:33 load average: 0.00 0.00 0.00

MichelRoy
Wed Dec 07 04:47:03 CST 2005

called recursively? then i hope your nlock variable is defined as local
would it be possible? just a fluke that the record is locked, it fails the
100th time
but before it execute the next line the sub gets called by another trigger
and sets nlock to 0. with autoyield set to .t., _vfp processes events between
each line of code. so it appears the record is locked but it isn't

"Paul Hemans" wrote:

> I don't want to use the default locking mechanisms, this code is called
> recursively and often, in database triggers.
>
> > You don't need your wait routine if you must get the rlock(), do you? I
> > see no abort mechanism if rlock() fails.... you could use:
> The wait routine is there to allow other processes time to complete, it is
> randomized to minimize lock contentions. The abort mechanism is there, the
> loop fails after 100 attempts.
>
> > Did you move the record pointer after the SCATTER in your "stuff"? Did
> > you SELECT another alias?
> There is no record movement or selecting of tables
>
>
>

Andrew
Wed Dec 07 04:57:47 CST 2005

"Paul Hemans" <pauln.o.s.p.a.m@laberg.com.au> wrote in message
news:uw6akOu%23FHA.532@TK2MSFTNGP15.phx.gbl...
>I don't want to use the default locking mechanisms, this code is called
>recursively and often, in database triggers.
>
>> You don't need your wait routine if you must get the rlock(), do you? I
>> see no abort mechanism if rlock() fails.... you could use:
> The wait routine is there to allow other processes time to complete, it is
> randomized to minimize lock contentions. The abort mechanism is there, the
> loop fails after 100 attempts.

Just an aside, can't you use
SET REPROCESS TO 100
or
SET REPROCESS TO x SECONDS
and then RLOCK()
instead of making your own loop?

--
Regards
Andrew Howell

MichelRoy
Wed Dec 07 06:13:02 CST 2005

add to the vfp10 wish list.

TLOCK(nMaxTimeToWait,...) && timed lock in milliseconds.
get rid of set reprocess


"Andrew Howell" wrote:

> "Paul Hemans" <pauln.o.s.p.a.m@laberg.com.au> wrote in message
> news:uw6akOu%23FHA.532@TK2MSFTNGP15.phx.gbl...
> >I don't want to use the default locking mechanisms, this code is called
> >recursively and often, in database triggers.
> >
> >> You don't need your wait routine if you must get the rlock(), do you? I
> >> see no abort mechanism if rlock() fails.... you could use:
> > The wait routine is there to allow other processes time to complete, it is
> > randomized to minimize lock contentions. The abort mechanism is there, the
> > loop fails after 100 attempts.
>
> Just an aside, can't you use
> SET REPROCESS TO 100
> or
> SET REPROCESS TO x SECONDS
> and then RLOCK()
> instead of making your own loop?
>
> --
> Regards
> Andrew Howell
>
>
>

Alan
Wed Dec 07 08:43:18 CST 2005

My bet is that the file in use error is from the memo file.

I have no clue why this would happen. When your "doing stuff" with the
varriables do you change the memos? IF not try removing the MEMO clause from
the gather and see if that fixes it. (or try replace additive with the memo)

Alan

"Paul Hemans" <pauln.o.s.p.a.m@laberg.com.au> wrote in message
news:O5QR8qs%23FHA.3676@TK2MSFTNGP12.phx.gbl...
>I got this error from one of my users. In the code below I am applying
>manual record locks, and I would assume that it would protect the code from
>another user attempting a header lock but they got a "File is in use" on
>the gather memo...
> This runs in a high speed environment and I cannot rely on the default
> Foxpro locking mechanisms.
> Should I apply another test prior to writing the values back to the table,
> and what would that test be if rlock() was already succesful?
>
> nLock = 0
> do while nLock < 100
> if rlock()
> nLock = 0
> exit
> else
> sleep(50 + int(rand() * 100))
> nLock = nLock + 1
> endif
> enddo
> if nLock = 0
> scatter memo name oTrack
> * .... do stuff with the variables
> * got a "file is in use.." error even though rlock() had been applied.
> gather memo name oTrack
> Unlock
> endif
>
>
>

Paul
Wed Dec 07 16:18:41 CST 2005

Yes, maybe that is it, the "stuff" code is manipulating the memo field

Paul
Wed Dec 07 16:19:15 CST 2005

It manipulates the values inside the memo field

Paul
Wed Dec 07 16:20:27 CST 2005

nLock is local

man-wai
Wed Dec 07 19:17:44 CST 2005

Paul Hemans wrote:
> Yes, maybe that is it, the "stuff" code is manipulating the memo field
>
>
I suppose the "stuff" should be manipulating the memory copy of the MEMO
field (after the SCATTER). I don't think GATHER would break the rlock()
you earned before the SCATTER....

--
.~. Might, Courage, Vision. Sincerity. http://www.linux-sxs.org
/ v \
/( _ )\ (Fedora Core 4) Linux 2.6.14-1.1644_FC4
^ ^ 09:16:01 up 7 days 20:52 load average: 0.00 0.00 0.00

man-wai
Wed Dec 07 19:22:07 CST 2005

Paul Hemans wrote:
> It manipulates the values inside the memo field

try this. add "SELECT tablename" before every calls to RLOCK(), SCATTER,
GATHER, ... in the section of codes of you posted to make sure that you
are in the right area.

--
.~. Might, Courage, Vision. Sincerity. http://www.linux-sxs.org
/ v \
/( _ )\ (Fedora Core 4) Linux 2.6.14-1.1644_FC4
^ ^ 09:20:02 up 7 days 20:56 load average: 0.01 0.02 0.00

Paul
Thu Dec 08 00:27:40 CST 2005

Writing the memo may require a file lock on the memo file as it attempts to
relocate the memo to the end of the file. I don't know how it works for
sure, but I believe that is how memo bloat occurs.

Cy
Sat Dec 17 18:16:44 CST 2005

Alan Sheffield wrote:
> My bet is that the file in use error is from the memo file.
>
> I have no clue why this would happen. When your "doing stuff" with the
> varriables do you change the memos? IF not try removing the MEMO clause from
> the gather and see if that fixes it. (or try replace additive with the memo)
>
> Alan
>
> "Paul Hemans" <pauln.o.s.p.a.m@laberg.com.au> wrote in message
> news:O5QR8qs%23FHA.3676@TK2MSFTNGP12.phx.gbl...
>
>>I got this error from one of my users. In the code below I am applying
>>manual record locks, and I would assume that it would protect the code from
>>another user attempting a header lock but they got a "File is in use" on
>>the gather memo...
>>This runs in a high speed environment and I cannot rely on the default
>>Foxpro locking mechanisms.
>>Should I apply another test prior to writing the values back to the table,
>>and what would that test be if rlock() was already succesful?
>>
>>nLock = 0
>>do while nLock < 100
>> if rlock()
>> nLock = 0
>> exit
>> else
>> sleep(50 + int(rand() * 100))
>> nLock = nLock + 1
>> endif
>> enddo
>> if nLock = 0
>> scatter memo name oTrack
>> * .... do stuff with the variables
>> * got a "file is in use.." error even though rlock() had been applied.
>> gather memo name oTrack
>> Unlock
>>endif
>>
>>
>>
>
>
>
>
I have found problems like this to go away if tablevalidate is set to 0.
Most other settings require header locking (both table and memo file)
as I understand it on updates. According to the help not setting to 0
can affect the ability too scale up usage. I found that changing that
setting made that error stop happening in our high usage apps.