CGI and DestroyStack property

Richard Gaskin ambassador at fourthworld.com
Thu Apr 27 10:42:30 CDT 2006


Tariel Gogoberidze wrote:
>> Because of what I mentioned earlier (separately
>> launched copies of the engine that quit after
>> processing), you can't reliably save data from
>> multiple users into the same stack.
> 
> I was aware that separate copy of the engine is launched on each call. I 
> just hoped that I can avoid implementation of pseudo record blocking  
> because users would read and write to their own custom property
> 
> But you are right of course, I just opened the same stack from both MC 
> and Rev and they opened two "RAM copies"  of the same stack. Stack saved 
> from one engine overwrites  changes in the stack saved from another 
> engine. How obvious, now when I see it :)
> 
> So, it seems reading if fine, each copy of the engine would open it's 
> own copy of the same stack and read from it, but writing requires some 
> management through assess flags in external file or whatever.
> I kind of remember somebody mentioned that with fast CGI involved it's 
> possible to keep revolution cgi-engine running?

It sounds like you could safely use a separate stack file for each user, 
which might also bring a modest performance boost since it would only be 
loading the data for the current user.

I have a bug reporting tool I'll be demoing at RevCon which uses that 
approach:  each user has a folder on the server, and while they can read 
files from any folder they only write to the ones in their own.

In your case that may be all you need.  With the bug tool I also needed 
to allow admins to write to those files, so to avoid conflicts I just 
write a flag file to the folder to note that it's being edited, and any 
attempt at write-access to the file first checks for that flag and 
reports to the user if the file they want is in use.  Once the save is 
done the flag file is deleted.

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com


More information about the metacard mailing list