On 11/2/05, Ben Parker <[EMAIL PROTECTED]> wrote: > This approach is effectively a SessionFileStore which uses the client as > the store. The clobbering problem is still there: the user can hit Page A > with Cookies of State 1, and then while Page A is loading the user hits Page > B and their browser sends the session data still in State 1. Then Page A > modifies the session data and sends to the client in State 2, then Page B > completes and sends the session data to the client possibly still in State > 1. Page B's version of the session data will clobber the version set by Page > A.
What if you created a SessionFilePerKeyStore which stored each key in the session dictionary in a separate file? It doesn't eliminate the problem entirely, but it might mitigate it enough. For example, if Page B is mucking with different session data than Page A there won't be any clobbering. I don't know if that applies to your particular app or not. In production, I've been using SessionMemoryStore. It's fast and clobber free. Of course, as you pointed, it doesn't distribute. -Chuck ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
