Warren Smith wrote: > I currently support a legacy web based application that is > implemented in Python CGI scripts with the session data stored > client-side > in hidden form > variables. Although the session form variables are protected from > manipulation by a checksum algorithm, this is still a non-optimal > solution. > > This is one of several reasons that I have been considering > the merits of > migrating the app to WebKit and using the built in session > support, but I > am unsure of the scalability of the WebKit session implementation. > > The CGI app currently runs on more than a dozen web servers > that share the > same webspace via NFS. The web servers sit behind an "ip > sprayer" (on the > outside they appear as a single server). Changing this > infrastructure is not an option. > > In the Application.config section of the WebKit Configuration > Guide, under > the SessionPrefix heading, it talks about using mod_rewrite > in conjunction > with a "hostname" SessionPrefix to avoid the need for > multiple app servers > to share session data. Does this imply that multiple app > servers can't > share session data? > > If I had an app server running on each of the web servers, could they > reliably share session data if the sessions were stored on > the NFS space > and the SessionStore was set to 'File'?
You could try this; I don't remember anyone on the mailing list having tried it though. You might run into problems when you have multiple simultaneous requests that are manipulating the same session. I think in that case, the last request to finish processing will save its session values, overwriting any changes that were made by the requests that finished earlier. In other words, if: - request A starts - request B starts - request A modifies the session - request B modifies the session - request A finishes - request B finishes I think that request A's changes to the session will be lost. This may or may not be acceptable for your application. The advantage of the memory-based session stores is that all session changes are immediately available to all servlets (although that can sometimes introduce timing-related bugs too!). You might be able to just ignore this problem, or maybe you could add some sort of locking to SessionFileStore to avoid the problem. I would also worry about performance of the NFS-based solution, and latency -- when a session gets saved to NFS is it then immediately available to the other boxes, or is there a delay? Maybe your "ip sprayer" can implement some sort of session affinity based on the SID cookie, so you can just use memory sessions? I wrote that stuff in the documentation about SessionPrefix and mod_rewrite and I was basically hinting at a low-tech (and untested) way to achieve session affinity by using a clever set of mod_rewrite rules. - Geoff ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
