We are doing some background-calculations on records. These records can be locked by other users at the same time so we do following loop (within a Thread):

while (errorcount<=3) and (not terminated) do begin
   if Terminated then Exit;

   try
      fInternalposition.edit;
      // do something, calculate and fill fields
      fInternalposition.post;
      break;
   except
      if fInternalPosition.state=dsedit then fInternalposition.Cancel;
      inc(errorcount);
   end;
end;

This is called from a thread, which has his own tedbsession, tedbdatabase etc. is this the correct way?
With this we have a cance 1 to 1000 that something happens which we've not found yet that server corrupts indexes and we get #601 for that row.

Should i use LockCurrentRecord or is the .edit enough? Would the LockCurrentRecord fire an exception if another user has locked the record with .edit?

Yusuf Zorlu
MicrotronX

Yusuf


You are doing things correctly as far as I can tell. You've isolated session, database, table which is correct.

Two things occur to me:

1. are you using optimistic or pessimistic locking. I've always used pessimistic and I'm not sure about what optimistic would do in a thread
2. do you have the new buffering mechanism turned on. If so you may have found a problem there.

The only other thing I can offer is sympathy - threads are not nice to debug


Roy Lambert

Roy, we are using pessimistic locking for this.

I'm searching for bug's awhile. Now it seems i have found one, if the application is beeing terminated and i don't terminate that thread ... something unplanned happens.

I have changed my thread so it gets stopped / terminated automatically if app is terminated and app waits till thread finished. Hope this helps to get things solved,

PS: Thanks for your sympathy

Yusuf Zorlu
MicrotronX

Yusuf,

<< This is called from a thread, which has his own tedbsession, tedbdatabase etc. is this the correct way?
With this we have a cance 1 to 1000 that something happens which we've not found yet that server corrupts indexes and we get #601 for that row.  >>

Are you *still* seeing this problem now that I added a fix for the row buffer corruption (specifically the row ID) caused by the multi-threaded client code ?

I didn't log this as an incident because I'm still waiting to hear back from you on whether you saw the new error check/code that I added to detect this condition.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

<< Are you *still* seeing this problem now that I added a fix for the row buffer corruption (specifically the row ID) caused by the multi-threaded client code ?


Hi Tim, in the last week after your update we have not seen this or till now no customer has reported it. If we get no calls for this in this week, we can be sure that the problem is solved.

This entry was only to hear from other developers if i'm doing things correct because our background-thread is still "alive".

Yusuf Zorlu
MicrotronX

Yusuf,

<< Hi Tim, in the last week after your update we have not seen this or till now no customer has reported it. If we get no calls for this in this week, we can be sure that the problem is solved. >>

Thanks.  That's good to know, but if you didn't change *your* code, then you should have at least seen some of those new "#1012 Row corrupt" error messages.  But, race conditions being race conditions, it's possible that it's just a timing thing.

<< This entry was only to hear from other developers if i'm doing things correct because our background-thread is still "alive". >>

No problem.  I know that you posted your message before I came up with the fix, but I wanted to follow up here since you posted it here.

Tim Young
Elevate Software
www.elevatesoft.com