Closed GoogleCodeExporter closed 9 years ago
I'd say in 2) the session will be loaded from memcached instead of creating a
new, if both contexts have identical msm configurations (share the same
memcached instances).
== With sticky sessions ==
2.b) When the request in 2) is finished, the session will be stored in
memcached, with the new/additional data from application B.
3.a) Now another request is made to application A, but now the session is
already existing in A, therefore it will not be loaded again from memcached.
3.b) When this request modifies the session, it will be stored in memcached
again, now overwriting the changes done before by application B in step 2a/b).
Thus, the session stored in memcached will not contain the complete information
from apps A and B and therefore this is not suitable for tomcat failover
handling.
== With non-sticky sessions ==
The session is loaded from memcached at the start of a request (when first
accessed to be more precise) and removed from the local session map at the end
of a request.
Therefore with non-sticky sessions the session in memcached will contain the
information from both apps A and B.
Cheers,
Martin
Original comment by martin.grotzke
on 18 May 2012 at 1:14
A solution would be to use membase / couchbase which supports the concept of
"buckets", so that you could use different buckets for different apps/contexts.
Btw, the generated JSESSIONID should be bound to the servlet context path, so
that it's not submitted by the browser when a request is made to another
servlet context.
Therefore the session id in two different applications should *not* be the same
but different. I'm not sure what your actual concern/issue is.
Btw (2): this discussion is more appropriate for the mailing list than an issue
tracker ;-)
Original comment by martin.grotzke
on 18 May 2012 at 1:19
Closed due to inactivity.
Original comment by martin.grotzke
on 31 May 2012 at 8:25
Original issue reported on code.google.com by
mic...@kroliczek.com
on 17 May 2012 at 11:21