Glenn,
The only framework I use is the Delphi Supplied TWebModule. I did
all the User and Session manager framework myself.
Thanks for your help, David too. I do appreciate it.
Doug
On 7/6/2010 2:09 PM, Glenn B. Lawler wrote:
> Doug,
>
>> 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.
>
> We build CGI from scratch using the W3C specification without any
> third-party frameworks. What you are describing above is not contained in
> the CGI specification, so I am assuming you are using a CGI framework that
> is managing these sessions. That is fine, as long as you understand exactly
> how it works.
>
>> Do you see any contention issues or race conditions in this?
> If the CGI framework you are using provides a way for you to easily run
> processes for more than one user at the same time, that is all you need.
>
> Glenn
> www.incodesystems.com
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Doug Hale
> Sent: Tuesday, July 06, 2010 2:47 PM
> To: [email protected]
> Subject: Re: [delphi-en] Prevent CGI interface timeout.
>
> 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: [email protected] [mailto:[email protected]] On
>> Behalf Of Doug Hale
>> Sent: Tuesday, July 06, 2010 1:20 PM
>> To: [email protected]
>> 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: [email protected]! 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]
