Hi,

We are using DBISAM 3.27 and we occasionally(read: "rarely"!) get the
"Generel lock failure with table xxx". We cannot seem to find any
pattern og any bugs, but the program is multithreaded and we suspect
that the error occures because some thread exceeds the "LockRetryCount *
LockWaitTime"-value....?

I was thinking about raising the LockWaitTime from 100ms til e.g. 250ms
og the LockRetryCount from 15 to 30....will this have any sideeffects?
Which one is better? will it affect performance?

Thanks in advance!

Best Regards
 Thomas

Thomas,

<< We are using DBISAM 3.27 and we occasionally(read: "rarely"!) get the
"Generel lock failure with table xxx". We cannot seem to find any pattern og
any bugs, but the program is multithreaded and we suspect that the error
occures because some thread exceeds the "LockRetryCount *
LockWaitTime"-value....? >>

Actually, those don't have any bearing on this type of error.  This error is
caused when DBISAM cannot internally acquire a read or write lock for the
purposes of updating the table or reading data from disk.  It can also be
caused by transactions that are too long.  Are there a lot of sessions
hitting the same database at the same time ?  Furthermore, are you using
transactions ?

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> skrev i en
meddelelse
news:8130C0BB-CE59-473A-A2D3-2ADCBF593C29@news.elevatesoft.com...
> << We are using DBISAM 3.27 and we occasionally(read: "rarely"!) get
> the "Generel lock failure with table xxx". We cannot seem to find any
> pattern og any bugs, but the program is multithreaded and we suspect
> that the error occures because some thread exceeds the "LockRetryCount
> * LockWaitTime"-value....? >>
>
> Actually, those don't have any bearing on this type of error.  This
> error is caused when DBISAM cannot internally acquire a read or write
> lock for the purposes of updating the table or reading data from disk.
> It can also be caused by transactions that are too long.  Are there a
> lot of sessions hitting the same database at the same time ?
> Furthermore, are you using transactions ?
>

Ah, ok...

The program consists of up to 3 threads hitting the same database(and
potentially the same tables) at the same time. The threads are very
"light loaded", they all access small tables and running simple queries
like "SELECT ID FROM MyTable WHERE SomeTimestamp>xxx". The tables are
small(<1000 records) and the queries is only executed once every 2-3
seconds per thread. So the queries should not lock the tables "that
hard"? Multiple of these programs can access the same database at
once...but i don't think there are more than 5-10 programs running at
any given time(giving a max of around 30 threads) ...

I'm not using transactions...

Ideas? I just received the error a couple of times again this morning
from customers... (Eurekalog rules

Thanks...

Best Regards
 Thomas

Thomas,

<< The program consists of up to 3 threads hitting the same database(and
potentially the same tables) at the same time. The threads are very "light
loaded", they all access small tables and running simple queries like
"SELECT ID FROM MyTable WHERE SomeTimestamp>xxx". >>

Have I looked at your multi-threading code before ?  If not, then it is most
likely due to an issue with the way that you're using the multiple threads
with access to DBISAM.  These types of errors are almost always caused by an
error of that variety, and this can be verified by simply running the same
functionality that is in the 3 threads as 3 separate processes instead.  If
the processes work okay, then there is an issue with the threading code.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> skrev i en
meddelelse
news:E38A2387-DA63-4370-92DD-7B15F5615FC4@news.elevatesoft.com...
> << The program consists of up to 3 threads hitting the same
> database(and potentially the same tables) at the same time. The
> threads are very "light loaded", they all access small tables and
> running simple queries like "SELECT ID FROM MyTable WHERE
> SomeTimestamp>xxx". >>
>
> Have I looked at your multi-threading code before ?  If not, then it
> is most likely due to an issue with the way that you're using the
> multiple threads with access to DBISAM.  These types of errors are
> almost always caused by an error of that variety, and this can be
> verified by simply running the same functionality that is in the 3
> threads as 3 separate processes instead.  If the processes work okay,
> then there is an issue with the threading code.
>

Sorry for the late reply...

The problem is that i cannot split it into 3 processes since the error
only occures 1/1000+ times and on remote locations on randomBut i
also belive that the error originates from wrong usages of threads with
DBISAM...

I don't think that you have looked at my code before...Can i talk you
into using 5 minutes looking at it if i send it via email to you?

/*Thomas

Thomas,

<< I don't think that you have looked at my code before...Can i talk you
into using 5 minutes looking at it if i send it via email to you? >>

Sure, no problem.  Send it over.

--
Tim Young
Elevate Software
www.elevatesoft.com