DanR
asked on
LockFile() delays
We have a proprietary database application running over a network. If the network is good, everything runs fine. However, many of our customers have (for one reason or another) considerable latency in their networks. On those networks, there sometimes is a serious delay whenever we call FileLock(), and this is causing application errors.
Does anyone know of a way to make FileLock() more tolerant of network delays?
Does anyone know of a way to make FileLock() more tolerant of network delays?
jkr
Do you mean 'LockFile()'? If so, 'LockFileEx()' might help...
I'm not sure I understand how solving a network letency issue with LockFile() is going to help. Assuming the underlying problem remains and by some means you got LockFile() to happen immediately, you're still going to be faced with the same latency for any subsequent read or write operation over that same network.
So by solving a problem with LockFile() you are only postponing the problem to a more in-opportune time.
It my opinion that a networked application such as this needs a solid network to support it. Otherwise, it like building a house with a foundation made of rotten wood. It's not going to hold up...
So by solving a problem with LockFile() you are only postponing the problem to a more in-opportune time.
It my opinion that a networked application such as this needs a solid network to support it. Otherwise, it like building a house with a foundation made of rotten wood. It's not going to hold up...
You should not be locking files in a database application. Instead, you should use the DBMS's record locking capability. Could you describe your problem in more depth? Thanks!
-- Dan
-- Dan
ASKER
I have to say that I agree with jhance, however the application is ours, while the networks belong to our clients. So their response is: "Everything else works fine over the network." In most cases, they aren't running any other applications else over the network, but they just don't want to hear it. When it comes right down to it, their network is what it is, and if our application won't run on it, then they'll look for something else.
DanRollins
This application was not built using a DBMS. It's built from the ground up in C++.
jkr
You're right, of course, that it's LockFile(). I took a look at LockFileEx(), but I couldn't see that it's behavior would be different in any way that might help.
DanRollins
This application was not built using a DBMS. It's built from the ground up in C++.
jkr
You're right, of course, that it's LockFile(). I took a look at LockFileEx(), but I couldn't see that it's behavior would be different in any way that might help.
I guess I just don't see HOW you're going to resolve this.
You have an application that is dependent on a balky network, but you can't fix the network.
Basically you're asking how to reliably get from point A to point B when there is only one road between the two and there is a bridge on the road that is often closed.
Options:
1) Build a new road that has a reliable bridge or choose a different mode of transportation that does not depend on the bridge.
2) Duplicate everything you have at A at B also so you don't have to move stuff in a hurry.
3) Move everything to B so you don't have to travel the road.
In terms of your problem:
1) Put in a dedicated network between your system and the DB.
2) Have redundant copies of the database and synchronize them when the network is good.
3) Don't run over the network at all, make the database local to the application.
You have an application that is dependent on a balky network, but you can't fix the network.
Basically you're asking how to reliably get from point A to point B when there is only one road between the two and there is a bridge on the road that is often closed.
Options:
1) Build a new road that has a reliable bridge or choose a different mode of transportation that does not depend on the bridge.
2) Duplicate everything you have at A at B also so you don't have to move stuff in a hurry.
3) Move everything to B so you don't have to travel the road.
In terms of your problem:
1) Put in a dedicated network between your system and the DB.
2) Have redundant copies of the database and synchronize them when the network is good.
3) Don't run over the network at all, make the database local to the application.
ASKER
jhance
I agree. What I was hoping was that someone knew of a way to redesign the vehicle to be better able to cross a shaky bridge. Or maybe amphibious code... Yeah...
Seriously, though, we can't stop the delay, but I'd like to have the application a little more tolerant of delays.
I agree. What I was hoping was that someone knew of a way to redesign the vehicle to be better able to cross a shaky bridge. Or maybe amphibious code... Yeah...
Seriously, though, we can't stop the delay, but I'd like to have the application a little more tolerant of delays.
Sometimes we are faced with problems for which there are no simple answers.
If getting networked apps running smoothly over a balky network was simple, there would be little need for creating programmers like us, right?
Somehow you're going to have to reduce or eliminate the dependency on a responsive network. I'm not sure it's going to be simple and it will certainly be a compromise. But that is the essence of software engineering in general, isn't it?
If getting networked apps running smoothly over a balky network was simple, there would be little need for creating programmers like us, right?
Somehow you're going to have to reduce or eliminate the dependency on a responsive network. I'm not sure it's going to be simple and it will certainly be a compromise. But that is the essence of software engineering in general, isn't it?
ASKER
I agree. Anyone have any suggestions for making LockFile() more tolerant of slow network response times?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> there sometimes is a serious delay whenever we call FileLock(), and this
>> is causing application errors.
You need to write your code to be more tolerant of the errors; that is, when it fails you need to retry rather than pushing on. Or do the file locking on a separate thread and have the main thread monitor its completion status. I suggest avoiding jkr's suggestion of using LockFileEx() with overlapped I/O because that would solve your problem too easily, and then you might be out of a job.
-- Dan
>> is causing application errors.
You need to write your code to be more tolerant of the errors; that is, when it fails you need to retry rather than pushing on. Or do the file locking on a separate thread and have the main thread monitor its completion status. I suggest avoiding jkr's suggestion of using LockFileEx() with overlapped I/O because that would solve your problem too easily, and then you might be out of a job.
-- Dan
ASKER
Thanks all. The advice was good, but jkr was the closest to a solution (even though we couldn't implement it).
Thanks! Out of curiosity, why couldn't you implement it?
ASKER
The main developer nixed the idea since it would require to much of a rewrite, and this is a legacy product that we're just trying to keep on it's feet for another year to give clients a chance to move to our Web app.
Ok, I *do* know that :o)
Thanx for the info...
Thanx for the info...