Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 20 total
Thread Index error 8965
Wed, Jan 11 2006 11:08 AMPermanent Link

I've just updated to DBISAM "4.22 Build 3" and I'm still getting the
DBISAM "index error 8965" reported from a test site. I upgraded because I
had this error a while ago, and upgraded and see it was updated again.

My app is doing multi-threaded read and writes of a database. My
understanding is that this is an error that was fixed, but I don't know if
I'm triggering something more, or if it is a problem in my code. Of course
I find it hard to repeat it here!

Essentially what I have is "two" threads. One runs and looks for work to
do in the database, and the "other" is created by RemObjects calls (and
hence there may be more than one). Actually, on checking I see there is
another session and table set on the main form, which may be relevant.

Okay, my worker checking thread does the following to create the session
and tables:
   m_xSession := TDBISAMSession.Create(nil);
   m_xSession.AutoSessionName := True;
   m_xWorkQuery := TDBISAMQuery.Create(nil);
   m_xWorkQuery.SessionName := m_xSession.SessionName;
   m_xUpdateQuery := TDBISAMQuery.Create(nil);
   m_xUpdateQuery.SessionName := m_xSession.SessionName;

The code that checks for something to do is as follows:

      if not m_xWorkQuery.Eof then
         m_xWorkQuery.Next;
      if m_xWorkQuery.Eof then
      begin
         m_xWorkQuery.Close;
         m_xWorkQuery.Open;
      end;
      if not m_xWorkQuery.Eof then
      begin
         SetState(csDoAction);
      end;
      result := not m_xWorkQuery.Eof;
Where a result of true means there is something to be done. The SQL for
the query is:
   szSQL := 'SELECT rsID, rsRequestTime, rsType, rsState,
rsBetFairID, rsParams ';
   szSQL := szSQL + 'FROM RequestStore ';
   szSQL := szSQL + 'WHERE rsState = 1';
   szSQL := szSQL + 'ORDER BY rsRequestTime ASC ';
   szSQL := szSQL + 'TOP 10 ';


The request threads are TRORemoteDataModule derived data modules, and the
session object on it has AutoSessionName set true.

First key is that the main form didn't have AutoSessionName set true. Does
this matter though, since it was the only one without it? The main form
has a timer that, at a certain point in the day will run a query to delete
old requests.

queryGrid.Close;
szDeleteSQL := 'DELETE FROM RequestStore WHERE rsRequestTime < ';
szDeleteSQL := szDeleteSQL + Engine.QuotedSQLStr(Engine.DateTimeToAnsiStr
(IncDay(Now, -14), true));
queryEmpty.SQL.Text := szDeleteSQL;
queryEmpty.ExecSQL;
LogReport(leInformation, 'Deleted ' + IntToStr(queryEmpty.RowsAffected)+ '
old requests');
queryEmpty.Close;
queryGrid.Open;   // try finally on this code removed for brevity.

So the million dollar question is what might be causing the index error
8965 to be occurring now? This is rather annoying to me since I've been
saying how good DBISAM is, and how it "just works", to a new employer
(contract) and this is happening on their customers test system! If need
be, I can let you have anything you need, but the app uses a login to a
remote system to do anything useful so it is hard to replicate.

All assistance much appreciated!

/Matthew Jones/
Wed, Jan 11 2006 11:30 AMPermanent Link

Okay, hold on this one a moment. Looks like the old version is still being
run... (Users, who'd have them!)

/Matthew Jones/
Wed, Jan 11 2006 3:05 PMPermanent Link

Okay, this is live again. Confirmed failing in my latest build with DBISAM
4.22. 8-(

/Matthew Jones/
Wed, Jan 11 2006 3:44 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Matthew


Start trying to build a demo for Tim Smiley

Multithreaded apps are a nightmare!

Roy Lambert
Wed, Jan 11 2006 4:51 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matthew,

<< My app is doing multi-threaded read and writes of a database. My
understanding is that this is an error that was fixed, but I don't know if
I'm triggering something more, or if it is a problem in my code. Of course I
find it hard to repeat it here! >>

Can you reproduce the problem ?  If so, then if you can send me the project
that is causing the problem, I can take a look and figure out hat is going
on.  9 times out of 10 the problem is with the coding of the threading, but
occasionally it is a DBISAM bug.


--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Jan 12 2006 5:04 AMPermanent Link

I'll try to make it repeatable, then send it to you.

/Matthew Jones/
Thu, Jan 12 2006 9:40 AMPermanent Link

Unfortunately, I've got it to fail here too. I have an app that fires 50
threads all initiating requests, and every 10 seconds the maintenance
cycle fires, deleting old items. The log shows:

        14:16:50.025   0   DBISAM version 4.22 Build 3
   [lots more snipped]
12/01/06 14:29:29   0   State:csDoAction
12/01/06 14:29:29   0   >>ProcessWork
12/01/06 14:29:29   0       Thread Test 14176
12/01/06 14:29:29   0   <<ProcessWork
12/01/06 14:29:30   0   State:csDoAction
12/01/06 14:29:30   0   >>ProcessWork
Thu 12 14:29:30.092   0   >>Automatic maintenance cycle initiated
12/01/06 14:29:30   0       Thread Test 14177
12/01/06 14:29:30   0   <<ProcessWork
12/01/06 14:29:30   0       Deleted 201 old requests
12/01/06 14:29:30   0   <<Automatic maintenance cycle complete
Thu 12 14:29:30.295   0   M:BACKGROUND ERROR: DBISAM Engine Error #
8965 Index page buffers corrupt in the table 'RequestStore'
Thu 12 14:29:30.295   0   M:BACKGROUND ERROR: DBISAM Engine Error #
8965 Index page buffers corrupt in the table 'RequestStore'

What is the best way for me to send you the source? The app uses
RemObjects, and has the DevExpress grid version 4 (though that isn't
actually vital TBH - I could easily delete it if it helps). Also Raize
Components v3 is used a lot. Oh yes, and it uses SVCom to make it into a
service. Thoughts?

/Matthew Jones/
Thu, Jan 12 2006 9:46 AMPermanent Link

The log segment I posted shows, by the way, a work unit (database read,
increment integer, write result to database) and a maintenance unit
(delete database items more than 14 seconds old) overlapping slightly, and
immediately afterwards something detects the 8965 index error and the app
effectively dies (it just repeats this message forever whenever it tries
to do anything).

/Matthew Jones/
Thu, Jan 12 2006 10:21 AMPermanent Link

I also note that I have a source license, so I wonder if there is a debug
version of DBISAM that might lend a clue for this? Some way of outputting
a log of what DBISAM is doing so that it can be traced here?

My latest test has been running for 20 minutes without failure. 8-(

I've got it so that it doesn't require an account any more though, so it
can be tried "standalone". It is in Delphi 7 pro BTW, if that makes any
difference? Is it worth me making a VMWare image of it so that you can
work on it?

/Matthew Jones/
Thu, Jan 12 2006 11:23 AMPermanent Link

More info on this perhaps:

I can get a situation where multiple threads are stuck trying to lock the
table. Is this relevant?

Let's go over my understanding of multi-threaded DBISAM. My understanding
is that all I have to do is make sure that each thread has a separate
session ID. To do that, the AutoSessionName can be set to true on forms
and data modules, and that "just takes care of it". For manually created
sessions, etc, I have to "wire" up the session name myself, but all that
is needed is to create the session, get it to auto-name, then use that
name in the queries that I create in that thread. (As per my code already
posted). I've just checked this with the manual, and all is well there -
nothing I'm not expecting.

I'll add a log item to output the session name for each thread, but beyond
that I'm open to any suggestions. Oh, and I have the madExcept dump from
the lock if that is of interest. The key parts are that there is one
delete, two inserts and a read all happening at the same time.

Before posting this, I thought I'd be sure of my sessions names. This is
odd. The main form has a session ID of "sessionServer_1". The state
machine which does the work has a session ID of "sessionServer_2". All of
the RemObjects data modules get a session ID of "sessionServer_3" or
"sessionServer_4". Never a 5 or anything more. Okay, on printing the
thread ID as well, they are always matching. I'm surprised at this given I
have 50 threads in the client, but it isn't relevant to the matter in hand
here - all the sessions are independent, but I can lock them and I can get
error 8965.

/Matthew Jones/

Page 1 of 2Next Page »
Jump to Page:  1 2
Image