Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 8 of 8 total |
Optimistic Locking/Refresh |
Thu, Jan 25 2007 12:04 PM | Permanent Link |
Norman L. Kleinberg | I'm fighting a strange 8708 error on a small LAN (dedicated SBS) and have a few of
questions. (DBISAM 3.03). 1. I've always understood Optimistic and Pessimistic locking as basically concepts (or approaches) to locking protocols; i.e. pessimistic is when you hold the record throughout the edit, optimistic is editing a disconnected set and then checking for changes upon an attempt to post. We have been using pessimistic; we do a .Edit on a record, change through DB aware controls (Delphi 5) and then Post. We still experience 8708 errors, and I understand this is a complex issue; however, I have seen references to optimistic and pessimistic SETTINGS for DBISAM tables. I don't see this property anywhere. Am I missing something in the docs or was this added in later versions? If so, what is the in-built setting for "my" version? 2. I've trapped the DBISAM_KEYORRECDELETED event in the EditError and DeleteErro handlers of the table "of interest". Is this 8708? It works correctly sometimes but I also have gotten separate, unhandled 8708 errors. Why would these clauses NOT handle some of these errors (I guess they must be occurring elsewhere but for the life of me I can't figure out where). 3. Finally, is there a place in code (an event, perhaps) where I could issue a Table.Refresh that would minimize the chances of getting the 8708 errors? Do I also need to issue FlushBuffers (again, where, AfterScroll, perhaps?) to insure that new data isn't kept cached on a workstation? I'm looking into disabling oplocks on both the Server and W/S but don't want to do too many things at a time. Any pointers would be appreciated. Norman |
Thu, Jan 25 2007 12:40 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Norman,
<< 1. I've always understood Optimistic and Pessimistic locking as basically concepts (or approaches) to locking protocols; i.e. pessimistic is when you hold the record throughout the edit, optimistic is editing a disconnected set and then checking for changes upon an attempt to post. We have been using pessimistic; we do a .Edit on a record, change through DB aware controls (Delphi 5) and then Post. We still experience 8708 errors, >> This is normal if you are getting the 8708 error when calling the Edit method. It simply means that DBISAM is telling you that the record that the user is viewing is not the same record that is about to be edited. Therefore, if you want to go ahead with the Edit you should handle the 8708 by refreshing the dataset and retrying the Edit: procedure TMainForm.WindowEditError(DataSet: TDataSet; E: EDatabaseError; var Action: TDataAction); begin Action:=daAbort; if (E is EDBISAMEngineError) then begin if (EDBISAMEngineError(E).ErrorCode=DBISAM_RECLOCKFAILED) then begin if MessageDlg('The record you are trying to edit is currently locked, '+ 'do you want to try to edit this record again?', mtWarning,[mbYes,mbNo],0)=mrYes then Action:=daRetry; end else if (EDBISAMEngineError(E).ErrorCode=DBISAM_LOCKED) then begin if MessageDlg('The table you are trying to edit is currently locked, '+ 'do you want to try to edit this record again?', mtWarning,[mbYes,mbNo],0)=mrYes then Action:=daRetry; end else if (EDBISAMEngineError(E).ErrorCode=DBISAM_KEYORRECDELETED) then <<<<<<<<<<<<<<<<<<< begin MessageDlg('The record you are trying to edit has been modified since '+ 'it was last retrieved, the record will now be refreshed', mtWarning,[mbOk],0); DataSet.Refresh; Action:=daRetry; end else MessageDlg(E.Message,mtError,[mbOK],0); end else MessageDlg(E.Message,mtError,[mbOK],0); end; << I don't see this property anywhere. Am I missing something in the docs or was this added in later versions? If so, what is the in-built setting for "my" version? >> Look at the TDBISAMSession.LockProtocol setting. The default is lpPessimistic. << 2. I've trapped the DBISAM_KEYORRECDELETED event in the EditError and DeleteErro handlers of the table "of interest". Is this 8708? >> Yes, that's it. << It works correctly sometimes but I also have gotten separate, unhandled 8708 errors. Why would these clauses NOT handle some of these errors (I guess they must be occurring elsewhere but for the life of me I can't figure out where). >> Is it on tables with BLOB fields ? If so, then the 8708 is coming from trying to open a BLOB field that has since changed since the record was last cached. << 3. Finally, is there a place in code (an event, perhaps) where I could issue a Table.Refresh that would minimize the chances of getting the 8708 errors? >> Sure, right before any time you issue an Edit, Delete, or any time you go to view or access a BLOB field. << Do I also need to issue FlushBuffers (again, where, AfterScroll, perhaps?) to insure that new data isn't kept cached on a workstation? >> No, that's a completely separate issue. << I'm looking into disabling oplocks on both the Server and W/S but don't want to do too many things at a time. >> Again, separate issue. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Jan 25 2007 12:59 PM | Permanent Link |
Norman L. Kleinberg | Tim:
The code you provided in your message is the code I have employed in my handlers (see, I DID RTFM ). It works fine. I just was curious, and panicked, when the app STILL threw 8708 errors. It turns out it was corrupted BLOB fields (more below). While it might be NICE not to have that message (i.e. data has changed and will now be refreshed) pop up often I want to insure that the handler I'm using is a proper (safe) way to handle things. I can worry about speed and convenience later. It appears that it (the handler) is, good. <<Look at the TDBISAMSession.LockProtocol setting. The default is lpPessimistic.>> Ahh, of course, TSESSION (uhh, sorry, TDBISAMSESSION)! <<Is it on tables with BLOB fields ? If so, then the 8708 is coming from trying to open a BLOB field that has since changed since the record was last cached.>> You see, my problem is that I always assume it's MY fault. Yes, it turns out that one of my client's operators was editing a record in my app and decided to open and play with Photoshop in the middle. He ran out of resources, the machine locked up and he shut it off. "Could THAT have caused the problem?" my client asked. When I repaired the table it reported several BLOB fields with problems. Makes me feel a LOT better. << 3. Finally, is there a place in code (an event, perhaps) where I could issue a Table.Refresh that would minimize the chances of getting the 8708 errors? >> I am going to throw the Refresh in BeforeEdit and BeforeDelete, see if it doesn't slow things down too much. << Do I also need to issue FlushBuffers (again, where, AfterScroll, perhaps?) to insure that new data isn't kept cached on a workstation? >> After some more research I realize that shared data is never cached at the workstation (good thing). The server, of course, is another issue. << I'm looking into disabling oplocks on both the Server and W/S but don't want to do too many things at a time. >> Again, separate issue. Agreed. Thanks much for your prompt and accurate response. Norman |
Fri, Jan 26 2007 3:16 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Norman,
<< You see, my problem is that I always assume it's MY fault. Yes, it turns out that one of my client's operators was editing a record in my app and decided to open and play with Photoshop in the middle. He ran out of resources, the machine locked up and he shut it off. "Could THAT have caused the problem?" my client asked. When I repaired the table it reported several BLOB fields with problems. Makes me feel a LOT better. >> Yes, BLOB corruption can also cause such a message because the BLOB signature isn't updated properly and so DBISAM constantly thinks that the BLOB being opened doesn't match the record. The BLOB signature is stored in both the BLOB and the record in order to ensure that they are both always in synch. << I am going to throw the Refresh in BeforeEdit and BeforeDelete, see if it doesn't slow things down too much. >> It shouldn't be too bad. It will only actually refresh things if the data has actually changed. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jan 31 2007 5:09 PM | Permanent Link |
Norman L. Kleinberg | Tim:
I've been away for awhile and didn't get a chance to post my further experiences. I realize this topic has been beaten to death but I DO have two specific questions: 1. You mention TDBISAMSession.lockprotocolsetting. On my 3.03 version of TDBISAMSession, I don't see this property as published and I don't see any reference to it in the help. Is it my error or did this property work its way into DBISAM at a later point? 2. I'm getting quite a few 8708s, apparently from BLOBs since they display a default error dialog and not the custom one I've written in the EditError and DeleteError handlers. In an old message you mention that the best way to handle these is to trap for them. Where would that be? In a ReadError nadler or somewhere else? Thanks for any info. Norman |
Thu, Feb 1 2007 4:03 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Norman,
<< 1. You mention TDBISAMSession.lockprotocolsetting. On my 3.03 version of TDBISAMSession, I don't see this property as published and I don't see any reference to it in the help. Is it my error or did this property work its way into DBISAM at a later point? >> It may have been added later. It's been so long that I can't really remember when we added the optimistic locking. << 2. I'm getting quite a few 8708s, apparently from BLOBs since they display a default error dialog and not the custom one I've written in the EditError and DeleteError handlers. In an old message you mention that the best way to handle these is to trap for them. Where would that be? In a ReadError nadler or somewhere else? >> The only place to trap them is in the Application.OnException handler. The reason that there isn't a nice place to trap them is because they are encountered during a read, not an Edit, Post, or Delete. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Feb 1 2007 5:20 PM | Permanent Link |
Norman L. Kleinberg | Tim:
----------------- << 2. I'm getting quite a few 8708s, apparently from BLOBs since they display a default error dialog and not the custom one I've written in the EditError and DeleteError handlers. In an old message you mention that the best way to handle these is to trap for them. Where would that be? In a ReadError nadler or somewhere else? >> The only place to trap them is in the Application.OnException handler. The reason that there isn't a nice place to trap them is because they are encountered during a read, not an Edit, Post, or Delete. -------------------- If the 8708s are due to simply not refreshing the dataset then I would assume that "the second time" one tried to read the memo (assuming the BLOB wasn't updated in that brief interim) the error would not appear. Is that correct? In general is there an implicit refresh after such an error? In my case, the 8708s were persistent and, in fact, they seemed to be spreading through the file like a virus. So I grabbed the table and found that these 8708s are the result of "Invalid Blob Handles"; when I verified the table quite a few of these showed up. Would 8708s by themselves (if due to records being updated by other stations) cause corruption? If not, I can only conclude that there is a flaky network card or cable, bad server or server setting (oplocks) that is causing this. The only other option is that 3.03 is particularly prone to this sort of corruption, in which case I will have to update to 3.3 (wow!) which does have a setting to turn on pessimistic locking. Thanks for any answers you can provide to the above two questions. Norman -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Feb 2 2007 5:36 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Norman,
<< If the 8708s are due to simply not refreshing the dataset then I would assume that "the second time" one tried to read the memo (assuming the BLOB wasn't updated in that brief interim) the error would not appear. Is that correct? In general is there an implicit refresh after such an error? >> No, you would need to refresh the dataset in order to force DBISAM to check for changes. << In my case, the 8708s were persistent and, in fact, they seemed to be spreading through the file like a virus. So I grabbed the table and found that these 8708s are the result of "Invalid Blob Handles"; when I verified the table quite a few of these showed up. Would 8708s by themselves (if due to records being updated by other stations) cause corruption? >> No, but 8708's can indeed be caused *by* corruption. << If not, I can only conclude that there is a flaky network card or cable, bad server or server setting (oplocks) that is causing this. The only other option is that 3.03 is particularly prone to this sort of corruption, in which case I will have to update to 3.3 (wow!) which does have a setting to turn on pessimistic locking. >> Well, frankly I would suggest upgrading to the latest 4.x first, and then 3.30 second. 3.03 is a very old version of DBISAM, and I really couldn't even tell you what issues might exist with it without going back through all of the incident reports for 3.x. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Thursday, March 28, 2024 at 06:18 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |