Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 6 of 6 total |
LockCurrentRecord or simply tEdbQuery.edit? |
Sat, Mar 16 2019 3:47 AM | Permanent Link |
Yusuf Zorlu MicrotronX - Speditionssoftware vom Profi | 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 |
Sat, Mar 16 2019 4:28 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Sat, Mar 16 2019 5:52 AM | Permanent Link |
Yusuf Zorlu MicrotronX - Speditionssoftware vom Profi | 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 |
Wed, Mar 20 2019 3:42 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Mar 25 2019 2:16 AM | Permanent Link |
Yusuf Zorlu MicrotronX - Speditionssoftware vom Profi | 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 |
Mon, Mar 25 2019 11:40 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |