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
_______________________________________________
metacard mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/metacard

Reply via email to