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?
LVL 3
DanRAsked:
Who is Participating?
 
jkrConnect With a Mentor Commented:
Have you tried 'LockFileEx()' with overlapped IO? This *should* work, as the completion event is only fired when the lock is granted...
0
 
jkrCommented:
Do you mean 'LockFile()'? If so, 'LockFileEx()' might help...
0
 
jhanceCommented:
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...
0
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
DanRollinsCommented:
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
0
 
DanRAuthor Commented:
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.
0
 
jhanceCommented:
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.
0
 
DanRAuthor Commented:
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.
0
 
jhanceCommented:
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?
0
 
DanRAuthor Commented:
I agree.  Anyone have any suggestions for making LockFile() more tolerant of slow network response times?
0
 
DanRollinsCommented:
>> 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
0
 
DanRAuthor Commented:
Thanks all.  The advice was good, but jkr was the closest to a solution (even though we couldn't implement it).
0
 
jkrCommented:
Thanks! Out of curiosity, why couldn't you implement it?
0
 
DanRAuthor Commented:
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.
0
 
jkrCommented:
Ok, I *do* know that :o)

Thanx for the info...
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.