Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Optimistic Locking/Refresh
Thu, Jan 25 2007 12:04 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 Smile). 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. Smile 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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. Smile 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 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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

Image