Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 13 of 13 total
Thread Strict change dtection revisited
Sat, Jun 30 2018 10:53 AMPermanent Link

Arthur Williams

Zarksoft

Avatar

Something that occurred to me, which I am going to test, is that this lack of detecting global table changes might invalidate table locking. It occurred to me that if a session isn't checking the table for status, then it won't see any locking. So I imagine that I could apply an exclusive lock to a table to prevent access while something happens, and all lazy change detection sessions will continue to present search results as if nothing is happening at the table level.

I'm thinking there might be a big integrity exposure here. Session A locks table. Session B ignores lock, only checks record to edit to see if different from original read. Record not changed, so Session B updates in place. Session A now comes along and edits record having depended on lock to preserve data. Session B update is lost.
Tue, Jul 3 2018 9:10 AMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

On 6/30/2018 10:53 AM, Arthur Williams wrote:
> Something that occurred to me, which I am going to test, is that this lack of detecting global table changes might invalidate table locking. It occurred to me that if a session isn't checking the table for status, then it won't see any locking. So I imagine that I could apply an exclusive lock to a table to prevent access while something happens, and all lazy change detection sessions will continue to present search results as if nothing is happening at the table level.

You cannot add exclusive lock if some other session has a read lock already.

Raul
Fri, Jul 13 2018 11:38 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Arthur,

<< Something that occurred to me, which I am going to test, is that this lack of detecting global table changes might invalidate table locking. It occurred to me that if a session isn't checking the table for status, then it won't see any locking. >>

No, that's not how it works.  DBISAM will not touch a table without first a) getting a *table-wide* read or write lock (depending upon the operation), and b) seeing if anything has changed.

Tim Young
Elevate Software
www.elevatesoft.com
Previous PagePage 2 of 2
Jump to Page:  1 2
Image