On Dec 4, 2005, at 3:38 PM, Alejandro Tejada wrote:
this is great, but just noticed
that this option is not included
or recommended in any message, tutorial
or page about using cgi in this platform.
Does exist risks for data loss when
multiple users save data to one stack
in the cgi folder?
Does exist the real possibility that many
users try to write the stack at the same
time and erase other users contributions
or (worse) damage the stack?
Alejandro,
yes, that is always a risk. This can happen, and in my own paranoic
opinion, if it can happen, it will happen. I'd recommend one of two
approaches to solve your problem.
(1) Use a second CGI/stack as a queue organizer. Your main cgi would
pass request to change the data stack to this queue organizer that
would put all requests on a queue and execute them when possible.
This is some work but it will keep you coding a 100% transcript
solution that will scale fine. The trick is: received a request then
queue, you can use a simple text file for queue and the standard file
locking algorithms for prevent concurrent access to the queue. This
can even be combined into one single CGI, no matter how many
instances of the CGI is running, they will all queue requests and
execute them in order, if you execute the queue after answering the
browser then you wont clog the user access and your queue routines
will run on dead time (dead time is the time between your cgi
answering the browser and it's exit from memory, during that period
you can do whatever you want since there's no http connection anymore
and no one waiting for answers, just use that CPU time!)
(2) That's the easy one. Use a RDBMS as data storage. It's not 100%
transcript since it involves some knowledge of SQL. You can use
MySQL, most ISPs support it to one degree or the other, or you can
opt to go with embedded solutions like altSQLite and Valentina. If
you use a RDBMS that supports transactions (such as postgreeSQL) then
you won't even need queue routines.
Cheers and good luck
Andre
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
