General information
Category:
Coding, syntax & commands
I don't see the at all the deadly embrace here...
Vlad
>Ok, let me try that again. . .
>
>When you update TABLE.DBF, do you:
>1) RLOCK table.dbf, then
>2) INSERT INTO thread, then
>3) Update table.dbf
>
>***OR*** do you
>1) RLOCK table.dbf, then
>2) update table.dbf, then
>3) INSERT INTO thread
>
>My point is simply this: *IF* you do the INSERT *while* the RLOCK is in place on table.dbf, then you run a risk of a "deadly embrace". This is as in the first example, above.
>
>If, however, your logic follows the second situation shown above, then you have little risk (I cannot say *none* because I am not at all sure of the impact of .CDX updates (and their locks)) of deadly embrace.
>
>Your situation would definitely sound like a "dead;y embrace' to me EXCEPT for the fact of you SET REPROCESS *and* the possible length (time-wise) of update to phDBASE table.
>
>Still, good luck,
>Jim N
>
> >>Does your logic lock/update/unlock the 'key' table *before* it does the INSERT INTO?, or do you do the INSERT INTO while the 'key table' is still locked?
>>
>>The key table, which is known here as THREAD, is never locked. The reference to the locked table was to TABLE.DBF, which is used to keep all the actual key.
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only