Geoffrey Talvola said: > Warren Smith wrote: >> 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. >> ><snip/> >> 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.
Good point. > 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. > If both requests were for the same url, then I wouldn't be worried about the above scenario since most likely request B will be the request whose session modifications I want to keep. However, even if the request was for the same url, the following scenario could occur: - request A starts and is delayed for some reason - request B starts - request B modifies the session and finishes - request A finally wakes up, modifies the session, and finishes This may be ok if both request A and request B are able to send output to the client (depends highly on the nature of the application). However, if request B is issued because the user gave up on request A, stopped it, and issued request B, then the only output that the client recieves (from request B) and the state of the session data (written by request A) could be inconsistent. It occurs to me that a file-based session store may present these problems even with only a single app server and local filesystem, since multiple threads in the same app server could just as easily interact in the ways described. I see from the source of SessionFileStore that this is a known issue that has yet to be resolved. > 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? > I believe that as long as all the boxes have the NFS space mounted read-write, the changes are available to the next NFS transaction regardless of which client it comes from. Obviously, performance would still be considerably worse than a memory-based solution. > 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. > Interesting ideas. I'll have to do some research on the ip sprayer. My first take is that while modifying the ip sprayer to do session affinity might be technically possible, it will probably not be acceptable (for political reasons I won't go into). Our web servers are not Apache, so using mod_rewrite is not an option. Our web servers may have an equivilent, though. I'll have to check. Unfortunately, changing web servers is probably not an option either(again, politics). Anyway, thanks for your response. It has been very helpfull. -- Warren Smith [EMAIL PROTECTED] ------------------------------------------------------- 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_id70&alloc_id638&op=click _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
