en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en nl en en en en en en en sl en en en en en de en en en en en nl en en en en en en en fr en en en en en en en nl en en en en sl en en en en en en en en en en en en nl en en en en en en en en en en en en en en en en en en en en en nl en en en en en es en en en en en en en en en nl en en en en sl en en en en en en en en en en en en en nl vi en en en en en en fr en en en en nl en en en en en en en en en en de en en en fr en en en en en en en en en pt en en en en en en
By logging into your account, you agree to our Privacy Policy, personal data processing and storage practices as described therein.
Forgot password or user name?
Search in titles only Search in PowerBASIC for Windows only
You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
All Time Today Last Week Last Month
All Discussions only Photos only Videos only Links only Polls only Events only
In the following function:
FUNCTION OpenDatFile(BYVAL fLock AS LONG) AS LONG LOCAL timeoutval AS LONG LOCAL u AS UserInfoStruc timeoutval = 1024 ERRCLEAR DO IF fLock THEN OPEN datfile FOR RANDOM LOCK READ WRITE AS #1 LEN = SIZEOF(u) ELSE OPEN datfile FOR RANDOM SHARED AS #1 LEN = SIZEOF(u) END IF IF ISFALSE ERR THEN EXIT DO END IF DECR timeoutval LOOP WHILE timeoutval IF ISFALSE timeoutval THEN FUNCTION = -1 END IF END FUNCTION
What is a good value for "timeoutval" in PB/CC and PB/DLL? I can't seem to get a good feel for it.
Home of the BASIC Gurus
Join Date: Nov 2002
22 Mar 2000, 10:20 AM
I see this often with database engines - when you try to open a file for exclusive use, you want the program to retry the open if someone else has it open. And, keep retrying until you can get the file. I have similar code, but uses a sleep in the loop and displays (optionally) a retry message if it fails after waiting the desired length of time. I use is specifically for a small shared file that is read/written to and then closed right after reading/writing.
Join Date: Feb 2003
22 Mar 2000, 10:36 AM
SLEEP is a great idea. But in this case, I can't display a "retry" option since the code is in a DLL called by a CGI application.
Home of the BASIC Gurus
Join Date: Nov 1999
22 Mar 2000, 12:20 PM
This is just a side note that might be of some interest regarding some information I read a short while back. If you are using a NTFS file system (or if the program might ever be put on NTFS,) having many file open and close statements can lead to drastic performance loss.
The example I read was PC mag stating that in one of their test of Windows 2000, while using Word 97, the Windows 2000 machine was much slower than the 98. Microsoft’s comment on this was that the function used many open and close statements for the task and that the extra security overhead of the NTFS file system greatly slowed the process down. They said that future versions of Word would handle the task in a different way as to prevent the many open and close statements.
What I have done in DOS apps running in Windows in the past is to use my own “file locking” ie just have a couple of bytes at the beginning of the file to state the current file lock state. With a bunch tweeking I was able to make it work smoothly on a single computer or on a NetBeui network. What it did was create a “white board” where many computers could share and edit the same file and have all updates immediate across all computers.
It didn’t work on TCIP, I’d imagine due to more advanced file buffering by the TCIP protocol. I’d guess though that it could work using the same or similar techniques if tweeked some more.
In DOS, I did tests and had many computers reading and writing to the same byte in a file repeatedly for some time (good for the hard drive I’m sure.) I never had any bad writes and I never had any bad reads. Was Windows just protecting my DOS app from potential problems? Are there any concerns with this in an all Windows app?
Any ways, with all that background, what I’m trying to say is: Is this a suitable work around or is there a much better way to do this in Windows that I have missed entirely? This will be used for the backend of a database that I want to be able to scale to any size (if reasonable of course)
Colin Schmidt & James Duffy, Praxis Enterprises, Canada
[This message has been edited by Colin Schmidt (edited March 22, 2000).]
Join Date: Sep 1999
22 Mar 2000, 01:07 PM
In my experience timeout values for file locking should represent “real time” values instead of number of iterations in a loop. For a CGI the ideal value is a function of the number of current active treads on the web server (if it can be obtained).
With this technique, we can ensure the maximum efficiency since on a busy web server more locking demands could be waiting for the particular file to become available (i.e. unlocked).
Sleep is a good idea if coupled with the value derived from the number of active threads on the server.
[This message has been edited by Siamack Yousofi (edited March 22, 2000).]
Join Date: Feb 2003
22 Mar 2000, 01:15 PM
There is no way for a CGI application to know how many active threads there are on the web server. Nor do I believe that information is actually useful.
I changed the timeoutval to 255 and added a "SLEEP 10" to the loop. I was able to execute 10,000 near simultaneous accesses to the CGI app and never had a single timeout occur, so I'm satisfied.
ps. In a CGI application, there is no way to keep the file open from one instance to the next, so OPEN/READ/WRITE/CLOSE in a single session is required.
Home of the BASIC Gurus
Join Date: Nov 2002
22 Mar 2000, 02:02 PM
Since the data files are on the same machine as the cgi script (probably), I would assume you wouldn't see much delay in the open/close anyway.
22 Mar 2000, 03:13 PM
Sleep is a good idea, lets the other process do its work faster.
If you are doing this under IIS and use ISAPI, you can take advantage of the fact that IIS wont freelibrary your dll till it shuts down. Then you can keep the file open between requests and only open/close with process attach/detach. Then wait on a mutex to control locking instead of trying to open over & over.
If you are using CGI and plan on heavy use, it might be worth the effort to consider using multi-tier with MSMQ or MQSeries so that your CGI stays small. Probably better overall, because it keeps things pseudo-transactional and the backend app can keep the file open or in memory.
Copyright © 1998-2022 PowerBASIC Tools, LLC - All Rights Reserved.
Powered by vBulletin® Version 5.7.0
Copyright © 2022 vBulletin Solutions, Inc. All rights reserved.
All times are GMT-5. This page was generated at 09:32 PM.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.