Re: Advice on mod_lisp-based web application.

Blaine <Blaine.M.Nelson@xxxxxxxxx> writes:

Alex and Tim,

Thanks for the advice. If a stateless interaction model will make my
problems vanish then I'm definitely interested in trying to change
things.

I do have a good deal of state in global variables. The
recommendation is to migrate those to "session variables". Might you
say a little more about session variables? Are these instances of a
data structure that includes session id information along with the
variable's value? Or something else?

Also, Alex wrote, "the only thing i can imagine that makes it hard to
make multi-user
application is having some calculations running persistently in the
thread.." The simulation (discrete event monte carlo type thing),
when run lots of times which I have to do to get statistically sound
results, can take a few minutes to run. Is this the sort of thing you
imagine as being problem? Or, might it be the case that if I migrate
state-preserving global variables to session variables, I will be
okay?

I guess another way of asking the question is this. Is the
elimination of global variables sufficient to allow multithreading?
(I'm using SBCL and the Debian common-lisp-controller).


Alex has already addressed your questions quite adequately, so I doubt I can
add much more. You seem to have the general idea - any variable or information
which is specific to a particular client request needs to be kept in a state
variable of some type and you need some mechanism to link client requests
together in order to know which state variables correspond with which client.
Any structure that meets your need, hash table, sequence, structure etc, can be
used.

If you don't have many state variables, you can even try using variables in web
forms. The server returns whatever result it generates and possibly records
state information in variables embedded in the form it returns. The user then
uses a submit button to send the next bit of data back to the server. The
server reads the (hidden) variables from the form to re-initiate state and then
processes the new bit of data.

Obviously, this will only work well when there are not too many state variables
to track. In some ways, its a poor 'cookies' alternative, but will work even
when users have cookies disabled.

Another approach which is beginning to gain increasing ground is to use
javascript and maintain more of the state init stuff in the browser and send it
to the server. However, as there are still considerable variations in
javascript engines, this can be more complex. However, it does allow things
like pages that are only partially updated rather than totally updated etc.

If your application is really quite complex, with lots of variables etc, you
can even use a database backend and have the information keyed to some unique
value that the server retrieves from the client (via a form variable, cookie or
possibly even url/path). You then have routines to save/restore state from the
database.

Note carefully Alex's comment about using a mutex or some other mechanism to
ensure serial access to variables. If you have multiple threads/processes
running, you can never rely on what sequence events can occur in. Generally,
you need to always keep this in mind when working with web apps. You have no
guarantee of number or order of client requests and therefore, cannot make any
assumptions about when resources are used. The way the server works can also be
something you need to keep in mind. I'm not sure about mod_lisp, but some
systems just execute a whole new instance, in which keeping things separate is
a bit easier, but communicating information between requests may be more
difficult. Other systems are a master system that just forks of threads or
processes, in which case you need more care, but communication between requests
is easier. I suspect mod_lisp is more like the latter as these systems tend to
be more responsive and less resource intensive.

Tim


--
tcross (at) rapttech dot com dot au
.