Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 6 of 6 total |
"Generel lock failure" and LockWaitTime? |
Mon, Sep 10 2007 6:02 AM | Permanent Link |
=?iso-8859-1?Q?Thomas_Eg_J=F8rgensen?= | 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 |
Mon, Sep 10 2007 11:00 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Sep 11 2007 2:12 AM | Permanent Link |
=?iso-8859-1?Q?Thomas_Eg_J=F8rgensen?= | "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 |
Tue, Sep 11 2007 1:59 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Oct 5 2007 8:12 AM | Permanent Link |
=?iso-8859-1?Q?Thomas_Eg_J=F8rgensen?= | "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 |
Mon, Oct 8 2007 11:34 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
This web page was last updated on Wednesday, June 12, 2024 at 01:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |