Chuck Esterbrook wrote:
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 If I understand you correctly, that would be kind of like having contexts within a session, where each session context can be independently stored or synced. Pretty interesting, especially thinking about different WebKit contexts (with different web apps) running under a single Application/AppServer. That approach could work if the application can be (re)structured to never need the same session data at the same time. At this point, I'm reconsidering using sticky sessions. The two major hurdles seem to be load-balancing correctly with "stuck" load, and recovering sessions if a server dies. I think a modified SessionDynamicStore would cover the latter. If the "Dynamic" part uses an in-memory database table (albeit one network hop away) to persist the sessions in addition to the MemoryStore, then when the server dies another server should be able to load the session from the database table. This eliminates the clobbering issue, except in the case of server death where recent session changes may not make it into both the MemoryStore and the "DatabaseMemoryStore". - Ben ------------------------------------------------------- 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 |
- [Webware-discuss] Anybody made a memcached Sessi... Hancock, David (DHANCOCK)
- Re: [Webware-discuss] Anybody made a memcac... Ben Parker
- RE: [Webware-discuss] Anybody made a memcac... Hancock, David (DHANCOCK)
- Re: [Webware-discuss] Anybody made a me... Ben Parker
- RE: [Webware-discuss] Anybody made a memcac... Geoffrey Talvola
- Re: [Webware-discuss] Anybody made a me... Ben Parker
- Re: [Webware-discuss] Anybody made ... Chuck Esterbrook
- Re: [Webware-discuss] Anybody m... Ben Parker
- Re: [Webware-discuss] Anybody m... Nick Murtagh