On Apr 26, 2006, at 21:53:08 -0700 (PDT), Jan Schenkel wrote:
I understand that when MC engine is used as CGI it
launches new instance on each call
-snip-
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?
You'd be much better off using a database to store the
information you wish to save on the server.
Right, but that's too easy :), as I mentioned I wanted to experiment
with MC CGI to see what it can do.
MC CGI would be on "regular" OS X (not server) on T1
network. Feasible ?
Since you need database access, you might want to grab
the revolution cgi-engine for Darwin:
<ftp://ftp.runrev.com/pub/revolution/downloads/engines/2.0/cgi/
darwin.sit>
I have it running already and yes, it's Darwin engine, but just curious
why you linked database access to 2.0 Darwin engine specifically?. Does
this mean that let's say Rev 2.7 engine used as CGI would have problems
with database access or I just misunderstood your phrase?
Also, read the relevant post on the runrev.com forum
in case you have problems to get it up and running.
Hope this helped,
Jan Schenkel.
Quartam Reports for Revolution
<http://www.quartam.com>
Thanks for tips and best regards
Tariel
_______________________________________________
metacard mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/metacard
