Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 11 to 18 of 18 total |
Client App freezes |
Mon, Dec 15 2014 12:29 PM | Permanent Link |
KyleL | Roy Lambert wrote:
KyleL As I said, if that happens I'd suspect a race condition somewhere, probably involving transactions. These are very hard to track down. Roy Lambert ------------------------- I know it's been awhile but wanted to bring another update on things with follow up questions. 1. We've verified that we are using FastMM in our server application, but the issues still occur. 2. We've update our application to try and reduce likely occurrences of transaction race conditions. We mainly did this by targeting the specific operations around which freezing seemed to most frequently occur, both in the large office dealing with this and smaller ones. Our developer looked over our code and made some changes. These efforts do not appear to have stopped the freezing and they still occur with the same regularity. Furthermore on this, when considering the notion that our client application might be triggering a race condition I must in response question that were this the case would freezing not occur more frequently from the outset? Taking our applications purpose and design in to consideration the end users essentially are performing the same 8-10 operations in their work flow through the course of the day, and there can be upwards to 50 users doing these workflows at the same time, but the freezing tends to occur only late in the day after all users have been using the application without error up to that point for 6-8 hours. At face value this suggests to me that some fault in the server engine is a more probable cause since the failure never seems to occur more quickly from the outset while our application is being used in full production, which when considering the number of tasks that would be repeated over and over by a large pool of users you would think the fault would be apparent more quickly than it actually is. Taking this in to consideration the next question I think we should ask is what happenings in the server application could gradually accumulate under heavy use through the course of run time and eventually fail 6-8 hours later? I'll continue to look for ways to track this down on our end, any other thoughts anyone would like to throw out would be appreciated. Thanks! |
Mon, Dec 15 2014 4:38 PM | Permanent Link |
Raul Team Elevate | On 12/15/2014 12:29 PM, KyleL wrote:
> 2. We've update our application to try and reduce likely occurrences of transaction race conditions. We mainly did this by targeting the specific operations around which freezing seemed to most frequently occur, both in the large office dealing with this and smaller ones. Our developer looked over our code and made some changes. These efforts do not appear to have stopped the freezing and they still occur with the same regularity. Did you do anything to try to find exactly where the freeze happens and what the app is doing ? (for example debug logging). > Furthermore on this, when considering the notion that our client application might be triggering a race condition I must in response question that were this the case would freezing not occur more frequently from the outset? Not if it's a specific event, sequence of steps or interaction with multiple clients applications that results in this happening. > At face value this suggests to me that some fault in the server engine is a more probable cause since the failure never seems to occur more quickly from the outset This is not something you can just reason out. Since you also have to restart the client apps it could be that that fixes the issue. There are all kinds of others things that happen during the day that can contribute to this (like the sleeping PC or app crashing on one PC or network problems. etc). You do need to try to get to the root cause : what operation causes this, at what part of code, is there an error thrown, etc. You're also using a version of DBISAM that is over 6 years old and you really should upgrade and make sure issue occurs with newer version. Raul |
Mon, Dec 15 2014 4:51 PM | Permanent Link |
KyleL | Raul wrote:
On 12/15/2014 12:29 PM, KyleL wrote: > 2. We've update our application to try and reduce likely occurrences of transaction race conditions. We mainly did this by targeting the specific operations around which freezing seemed to most frequently occur, both in the large office dealing with this and smaller ones. Our developer looked over our code and made some changes. These efforts do not appear to have stopped the freezing and they still occur with the same regularity. Did you do anything to try to find exactly where the freeze happens and what the app is doing ? (for example debug logging). > Furthermore on this, when considering the notion that our client application might be triggering a race condition I must in response question that were this the case would freezing not occur more frequently from the outset? Not if it's a specific event, sequence of steps or interaction with multiple clients applications that results in this happening. > At face value this suggests to me that some fault in the server engine is a more probable cause since the failure never seems to occur more quickly from the outset This is not something you can just reason out. Since you also have to restart the client apps it could be that that fixes the issue. There are all kinds of others things that happen during the day that can contribute to this (like the sleeping PC or app crashing on one PC or network problems. etc). You do need to try to get to the root cause : what operation causes this, at what part of code, is there an error thrown, etc. You're also using a version of DBISAM that is over 6 years old and you really should upgrade and make sure issue occurs with newer version. Raul -------------------- All valid points, thank you. Should anything else noteworthy be discovered in our troubleshooting of this I will be sure to update/inform this thread accordingly. |
Tue, Dec 16 2014 4:07 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Raul
>You're also using a version of DBISAM that is over 6 years old and you >really should upgrade and make sure issue occurs with newer version. I agree with everything you've posted apart from this. Throwing a technology change into the mix without solving the problem first is, in my opinion, madness. Roy Lambert |
Tue, Dec 16 2014 4:17 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | KyleL
Rereading your initial post and I'm wondering about this <<we have a main session thread and a secondary one used for speeding up calculations when they are on the relevant segment of our application>> Is it possible to move everything into the main thread for a test period? Roy Lambert |
Tue, Dec 16 2014 8:28 AM | Permanent Link |
Raul Team Elevate | On 12/16/2014 4:07 AM, Roy Lambert wrote:
> I agree with everything you've posted apart from this. Throwing a technology change into the mix without solving the problem first is, in my opinion, madness. This is the same dbisam version as before (v4) and just newer build. The dbisam usage at code level has not changed so likely no code changes are required. There have been some big changes underneath like blob handling and more importantly large number of dbsrvr enhancements (4.29b3 and 4.35) not to mention various bug fixes and enchancements. At this point I would consider risk acceptable - especially since OP goes back 2 months without success yet. Not to mention that should this require dbisam changes those would likely only be available in 4.40 build. Raul |
Tue, Dec 16 2014 8:33 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Raul
I have to apologise. For some reason my eyes saw DBISAM but my brain said Delphi. I actually read it several times before making the post and each time it said Delphi. I read it now and it says DBISAM. My statement should now read I agree with everything you've posted. Roy Lambert |
Tue, Dec 16 2014 9:56 AM | Permanent Link |
Raul Team Elevate | On 12/16/2014 8:33 AM, Roy Lambert wrote:
> I have to apologise. For some reason my eyes saw DBISAM but my brain said Delphi. I actually read it several times before making the post and each time it said Delphi. I read it now and it says DBISAM. No prob. There are times i swear Tim's NG software adds typos into my posts as they looked just fine when i read then before posting and then seeing my own post i go "oops". Raul |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, April 23, 2024 at 08:10 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |