You could either modify session handler or if you have not witten any code just implement some sort of self.sessionSave() function that looks like session.value, but talkes to a db instead.
-Aaron
Warren Smith wrote:
Geoffrey Talvola said:
Warren Smith wrote:
<snip/>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.
If I had an app server running on each of the web servers, could theyYou could try this; I don't remember anyone on the mailing list having
reliably share session data if the sessions were stored on
the NFS space
and the SessionStore was set to 'File'?
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.
------------------------------------------------------- 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
