If want to store my web application session to different storage, because one every new request user might use different node, is it possible to override default container session storage?
You do not need to overrride anything. It should come with the server you are using. You need to look at "Session replication". In clustering environments, the app server can be configured to replicate session across nodes.
You will need to check documentation of the app server you are using to figure out how this can be enabled.
Please checkout the memcached-session-manager. It stores the session in external memcached server and works for both sticky-session and non-sticky-session(which is your case) scenario.
Related
Say I have 2 web applications. One is on a tomcat server and uses java. Abother is written in ASP.NET and is on an IIS server.
I want users to be able to log in on the IIS web application handling authentication, and if through a link they access a page hosted on my tomcat, I want them to be logged in. Both systems can access any/all databases in the background. I also have reverse proxies (F5 devices) at my disposal. The separate systems How could I achieve this?
One solution is to use something called Jespa: http://www.ioplex.com/
Here is another SO question regarding this setup: Tomcat Integrated Windows Authentication across Multiple Domains
My suggestion:
Generate a signature binding with userID and store it somewhere if some one succeeds in loggin in
Add this signature to the url on the IIS web page,and then goes to tomcat pages
Validate this signature which stored before and create session by the userID
I am using Jboss server. Whenever trying to restart server my application is getting logged out. I wont allow user to logout until Log off the applicaion. How to manage this thing. Like gmail i need to do.
You can do it by HA Web Sessions via Database Persistence.
The basic use case we hear for this is environments where sessions need to be available to AS instances located across a WAN. JBoss Cache/JGroups clusters can span a WAN but often users find it impractical to configure their cluster(s) in that way. However, their IT infrastructure already supports making RDBMS data accessible across the WAN. So, persisting sessions to the DB makes them available across the WAN.
For more details visit here
I want to run my tomcat-instances in a configuration where requests are served to several tomcat-instance via round robin. I don't want to use any internal cluster manager.
As far as I see if every request is served by different tomcats, an unknown sessionId would arrive at a tomcat, so it would be forced to create an new session and overwrite the old sessionId. So for every request a new session would be created. This seems to be a lot of overhead.
Is my view on that things right? Is there a way to disable tomcats sessions management?
Regards,
Michael
Basically you have two choices:
1) Replicate your sessions so they become reachable by any Tomcat node. Solutions: Tomcat Cluster, memcached-session-manager, possibly others.
2) Use a load balancer and implement sticky sessions. First requests will be routed randomly on a round robin basis, but subsequent requests will stick to the same server. Solutions: mod_proxy, hardware traffic managers.
The disadvantage of the first option is that session replication is costly, not very reliable and often requires Serializable-only data to be put in session.
The disadvantage of the second approach is that if you shut down your Tomcat for maintenance, the users will be forced to log in again.
You are incorrectly assuming that "for every request a new session would be created". The new session will be created only if not created before on that same server, or if it was created but already expired.
We usually used Tomcat behind an Apache web server with mod_jk for load balancing the requests across the Tomcat instances.
With sticky sessions a user will only get a session upon the first request and will afterwards always be directed to the Tomcat from where his session originates. So there is no need to replicate sessions across all Tomcats and the requests will be distributed across the Tomcats, too.
Of course, this does not ensure some kind of round-robin which you asked for.
A session will only be created once your code requests the session so if your application doesn't require the session then just simply dont access it. Checkout the section on getSession() in HttpServletRequest
http://download.oracle.com/javaee/5/api/javax/servlet/http/HttpServletRequest.html#getSession(boolean)
I'm not sure if there is a way to replicate the session across different tomcat instances however if you require some user state without session then you can use cookies instead.
EDIT: If you do need to replicate the session you could probably start by reading this tomcat document.
http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html
Is it possible to override Tomcat's embedded generator of JSESSIONID, to be able to create custom values of this cookie, based on user's login?
Why do I need this: I have a load balancer with "sticky sessions", configured to route requests with the same JSESSIONID to the same server, and I want to prevent situation, when same user can start two different sessions on different servers.
P.S: all this is about Amazon EC2
There is a better way to do this: See the tomcat manual on session replication in cluster
You can do so by defining your own customized session manager,
http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html
However, it probably doesn't work for your use-case. You don't know username before user logs in but the session needs to be created for the login.
I think pushing session to the backend is the best approach. You can use the JDBCStore session manager distributed with Tomcat. You can also find implementation for memecached.
If the purpose of multiple servers is for redundancy, you can also use clustering but that doesn't help you if your goal is to scale for load.
I'm having an inconvenient dealing with sessions..
I have this:
www.mydomain.com
sub1.mydomain.com
sub2.mydomain.com
sub3.mydomain.com
and when I log into "www", then I change to "sub2" (for example) I
figure out it creates another session :S
why is that??
I need the same session for www, sub1, sub2, sub3, and so on.. ALL in
"mydomain.com"..
what can I do?? is it like that and I have to make a trick?? or is
there a "legal" solution for what I want??
The JSESSIONID cookie is issued by the container, and the cookie domain and path is always that of the web application's domain and context root.
It appears as if you have multiple applications in which case, the JSESSIONID issued by one application will not be recognized by another, due to a change in either the domain or the context root, even if the applications are in the same container.
There are multiple ways to deal with this:
If you are not dealing with a high-value application, and if you can guarantee that no 'rogue' applications will be deployed on the server, you can configure the server to share sessions across applications. Weblogic Server can be configured to do this.
Use a central authentication and session management provider - SSO.
Use TLS/SSL - most servers do not issue a JSESSIONID cookie when communication is over SSL, and instead use SSL itself to store state. You will have mixed results here.
Update:
Glassfish v3 allows you to set the domain for the session cookie. This is done via the session-config element in sun-web.xml. I'm not sure if this is available in v2 or lower versions of Glassfish.
Yes, it is like that because you will have separate session cookie for every different domain. Which web server do you use ? You may implement SSO related solution to share data across the domains.
Look at this tutorial: http://javadude.wordpress.com/2011/05/12/glassfish-3-1-%e2%80%93-clustering-tutorial-part2-sessions/
I summarized all steps for Glassfish 3.1 and session replication