General information
Category:
Coding, syntax & commands
Mark,
>
>i disagree. if table.dbf remains locked durint the insert-sql then no other user can lock table.dbf and therefore can not procede on to the insert-sql step. to me this is better solution -- do not unlock table.dbf until after insert-sql. this will assure only 1 insert-sql can occur at any one time and response times should be acceptable.
The above is a very good theory, but in my humble opinion is begging for a deadly embrace situation *somewhere*.
Here's how my theory goes. . .
You cannot have a deadly embrace when you are updating only ONE table.
Since it takes updating at least two tables (update required because that's where locks come in) to get a deadly embrace, then *IF* all updates occur in the SAME SEQUENCE (as per your 'theory' above), then there is also no possibility of a deadly embrace.
However, all that is needed to change that situation for *ALL* participants is one rogue application where the sequence is not maintained. Let's face it, THIS IS A VERY LIKELY SCENARIO in any application set (it will likely not be the case that an app always updates a specific set of tables in a specific sequence.
So, the only "safe" way to code things is, when possible, to lock/update/unlock a single table at a time.
Cheers,
Jim N
Previous
Next
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