-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Leon,
On 11/16/11 5:32 PM, Leon Rosenberg wrote: > Hello Chris, > > thank you for the answer, more inline. > >>> User logins on http://www.site.fr, a new session is created. >>> User uses the site, attributes are written and read... User >>> clicks a special link and is redirected to >>> https://secure.site.com - secure.site.com (same webapp, >>> different servers) loads the session previously initialized on >>> www.site.fr and associates it locally. >> >> How does this work? Or, were you asking if Tomcat can make this >> work (easily) for you? > > Yes. I know/can think about other solutions where the session id > of the original session is transmitted via additional parameter and > is used for session copy, like: server A issues session AAA. link > to server B contains sessionIdParameter=AAA a vavle or something on > server B notices that there is no local session for user on server > B yet and copies the AAA session. > > The question was, does tomcat support this already, or would I have > to code something myself. URL rewriting is not an option for > several reasons. You'll have to roll your own, here. If you don't mind passing-around a meta-session-id, you could use something like memcached as a unified session that everyone can see. >> Unfortunately, you may have a shitstorm of session chatter. >> Presumably, you'll have a number of domain-specific servers and >> a single secure one (or clustering all around, which actually >> makes the chatter problem worse). That means that if you have 100 >> sessions on each of 10 CCTLD servers then you'll have 10000 >> sessions on the secure server. If that's okay, then go for it. > > Either you miscalculated it or I don't get the relation, 10x100 = > 1000, not 10.000 ;-) Too much coffee makes my fingers twitchy. 100 sessions per server is nothin', too. > But the point is valid, after the user leaves secure.site.com he > will probably never come back and there is no need to keep his > session (noone pays twice ;-)). You obviously need to change your business model. :) > But I assume tomcat session replication support doesn't support > session purge, neither session pull instead of permanent > synchronization. I don't think you can tell another node to purge a session without purging it from the entire cluster. Someone with more cluster experience than I can probably comment on that, but it's a safe bet :) With something like memcached, the "session" exists in the service and not in the server so it's not like you're wasting memory waiting for the session to die on the payment server. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FccEACgkQ9CaO5/Lv0PCkFQCfdq3nr85ZoMWryYzoGt2FuTuS 6UYAn27fnaH6+jQ79N1DD3auGwnWzcNr =iZQ4 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
