wang-haha / memcached-session-manager

Automatically exported from code.google.com/p/memcached-session-manager
0 stars 0 forks source link

Web Application Context Path support #135

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I haven't look at source yet and before i do that i want to ask something: 

Every web application is running in ServletContext, so as I understand there is 
possibility that applications A and B have same JSESSIONID.

Is that supported by MSM?

Example:
1) create http session in application A
2) make request to application B with JSESSIONID from 1)

What will happen? Second session will be created and sent to memcache? 
Will be session from 1) overwritten or second session from 2) would have own 
instance in memcache?  Or session from 1) would be used in instead of creating 
new?

Best regards to you
Michal 

Original issue reported on code.google.com by mic...@kroliczek.com on 17 May 2012 at 11:21

GoogleCodeExporter commented 8 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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
Closed due to inactivity.

Original comment by martin.grotzke on 31 May 2012 at 8:25