People usually use SessionManager to keep the session variable for each web agent. But these values will be lost if the server is crashed or redeployed.
I can think of some way such as save session to an external memcached, database or file, but I'm not sure which way is suitable to face with security problem and perform the best performance.
How can I keep sessions alive after restarting the service?
Related
I have a problem with sparkjava, when i restart the webserver, all the sessions created before the restart are invalidate (or deleted, do not know). How i can prevent that? It's a very annoying issue
You should persist sessions info in database like Redis, on keep in memory service like memcached.
This way you can also serve users using many computing point under a load balancer like nginx.
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
If i share session(HTTPSession) of one java web application deployed and running on a dedicated machine in tomcat with other java web application deployed and running on a separate machine in tomcat, will the session time out get affected?
i mean if i jump from one app to another in a different browser window with the same session, will the first app timeout and vice versa?
Every session is managed by the underlying container, so two containers will not communicate to see if session should be timed out or not.
So say your tomcat may timeout your session as per the configuration even if same session is being used in another container and is still active.
Also it is not a recommended approach to share session between JVM's as not all containers will allow you to do that. I think WSAD allows you to do that, but instead of sharing session, I would suggest you to share objects instead.
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
Tomcat (version 5 here) stores session information in memory. When clustering this information is periodically broadcast to other servers in the cluster to keep things in sync. You can use a database store to make sessions persistant but this information is only written periodically as well and is only really used for failure-recovery rather than actually replacing the in-memory sessions.
If you don't want to use sticky sessions (our configuration doesn't allow it unfortunately) this raises the problem of the sessions getting out of sync.
In other languages, web frameworks tend to allow you to use a database as the primary session store. Whilst this introduces a potential scaling issue it does make session management very straightforward. I'm wondering if there's a way to get tomcat to use a database for sessions in this way (technically this would also remove the need for any clustering configuration in the tomcat server.xml).
There definitely is a way. Though I'd strongly vote for sticky sessions - saves so much load for your servers/database (unless something fails)...
http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html has information about SessionManager configuration and setup for Tomcat. Depending on your exact requirements you might have to implement your own session manager, but this starting point should provide some help.
Take a look at Terracotta, I think it can address your scaling issues without a major application redesign.
I've always been a fan of the Rails sessions technique: store the sessions (zipped+encrypted+signed) in the user's cookie. That way you can do load balancing to your hearts content, and not have to worry about sticky sessions, or hitting the database for your session data, etc. I'm just not sure you could implement that easily in a java app without some sort of rewriting of your session-access code. Anyway just a thought.
Another alternative would be the memcached-session-manager, a memcached based session failover and session replication solution for tomcat 6.x / 7.x. It supports both sticky sessions and non-sticky sessions.
I created this project to get the best of performance and reliability and to be able to scale out by just adding more tomcat and memcached nodes.