On 7/6/2010 1:16 PM, Glenn B. Lawler wrote: > Doug, > > That will work, but you should also consider what would happen if another > web user requests this service while it is processing another request. There > are a lot of way to handle that situation. The way we normally do this is to > setup a unique session cookie that would contain a name that could be used > as a file name or directory name to keep the multi-user environment > separate. We normally do this for other reasons anyway, but you do not need > to use cookies. Your CGI could just use the API call to generate a GUID > (Guaranteed Unique IDentifier) which could then be used as a file name. That > file name would be the name used for both the status file and the output > file. There is a session for each user. The session state is maintained on the server, the cookie just identifies the session. The session state would maintain the "busy" state. The page generated by the Shelled app would contain the user name.
> Another thing to point out is that when your status page autorefreshes, it > does not need to point to your CGI each time. It could work just as you > describe, but I would probably use the simpler approach of having your > initial CGI write out the status page to the same file name that will > eventually contain the final output. This status page would contain the > autorefresh tag. The spawned process that does the work would write its > output to another file and when finished, it would delete the status page > file and rename its output file to the same name as the status page. That > way, the page the client is autorefreshing will "instantly" become the > output page whenever the processing is complete. Unless the page is being written out by the shelled app when the refresh occures, that could get messy. > Finally, you need to have a way to automatically clean up all these output > files. We normally do this with another process that is running on the web > server and automatically deletes all files older than a certain age. You > could also do this in the process that you spawn to do the processing if you > are using a hosting service and do not have access to the server, so that > every time you run the process, it first deletes all output files that are > more than 20 minutes old (or whatever criterion you choose). When the user logs out, the session is destroyed. There is also a service running that watches session states. If they get too old, they are destroyed. (Session states are updated at every request so the time on the session state represents the time of the last state) The only contention problem I see now is signaling completion. If the Shelled App uses the session state, it could be accessing it when the refresh occurs. But if I use the existence of the page file as the completion signal, then the session state does not have to be accessed by the Shelled App. And since, in Windows, the newly created file is not visible until it is closed, I won't have a race condition here either. So, during the refresh, if the file does not exists, send another "busy" page. If the file does exists, clear the "busy" status in the session state, send the page and delete it. Do you see any contention issues or race conditions in this? Doug > Glenn Lawler > www.incodesystems.com > > -----Original Message----- > From: delphi-en@yahoogroups.com [mailto:delphi...@yahoogroups.com] On Behalf > Of Doug Hale > Sent: Tuesday, July 06, 2010 1:20 PM > To: delphi-en@yahoogroups.com > Subject: Re: [delphi-en] Prevent CGI interface timeout. > > Ok, I'm a little slow today, but I think I've figured out what you all are > trying to tell me. > > 1) check to see if the work is already in progress > if not > 2) ShellExecute another program to do the actual work > 3) return an initial page with the wait message to the user and > the autorefresh > if so > 2) see if the work is done > if not > 3)return another message or partial results and > autorefresh > if so > 3) return the results > > This should work, thanks > Doug > > autorefresh - is that<meta http-equiv="refresh" content"30"> for a 30 > second wait. > > > > > > ------------------------------------ > > ----------------------------------------------------- > Home page: http://groups.yahoo.com/group/delphi-en/ > To unsubscribe: delphi-en-unsubscr...@yahoogroups.comyahoo! Groups Links > > > > > > > ------------------------------------ > > ----------------------------------------------------- > Home page: http://groups.yahoo.com/group/delphi-en/ > To unsubscribe: delphi-en-unsubscr...@yahoogroups.comyahoo! Groups Links > > > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.830 / Virus Database: 271.1.1/2985 - Release Date: 07/06/10 > 00:36:00 > [Non-text portions of this message have been removed]
