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