Sharing Session Data Between Contexts in Tomcat

Sharing session data between contexts in Tomcat

That article is indeed heavily outdated.

On Tomcat 5.5 and 6.0 you can just set emptySessionPath attribute to true in the <Connector> element in /conf/server.xml.

<Connector ... emptySessionPath="true">

On Tomcat 7.0 this has changed because this is now configureable from the Servlet 3.0 API on. It's then on Tomcat's side configureable by setting sessionCookiePath to / in <Context> element in any responsible context.xml file.

<Context ... sessionCookiePath="/">

As said, there's a new Servlet 3.0 API which allows you to configure the session cookie through the standard API. You can do it either declaratively by adding the following to the web.xml:

<session-config>
    <cookie-config>
        <path>/</path>
    </cookie-config>
</session-config>

or programmatically by SessionCookieConfig which is available by ServletContext#getSessionCookieConfig().

getServletContext().getSessionCookieConfig().setPath("/");

You could do this in ServletContextListener#contextInitialized() or HttpServlet#init().

See also:

• Tomcat 5.5 HTTP connector documentation
• Tomcat 6.0 HTTP connector documentation - mentions potential security hole
• Tomcat 7.0 context documentation

Any way to share session state between different applications in tomcat?

You should not share HttpSession; but you can share other objects. For example, you can register an object via JNDI and access the same object in all your apps (databases use this to pool connections).

Session sharing between contexts doesn't work on Tomcat 7

Sessions are never shared between web applications although session IDs might be depending on configuration. When an ID is shared sessions are created in each web application in the normal manner but they will share a common ID.

sharing session attribute between two subdomains in tomcat

I find solution my self.
I successfully get sharing session between two domain and now just my problem was identify same user.
When i try for sharing session data between those two domain and sub-domains at that time it's not work because server maintain session for individual application.

Now my solution is:

In Tomcat server there is context, In context we can store Object and same Context can be accessible by every application in same Tomcat. So Now
I create on java.util.Map object in java.util.Map object store key-value pair in which key is JSESSIONID and value is user Id who login. So now i can access easily user who login in domain and all sub-domains.

Tomcat ServletContext vs JNDI for Sharing session data across multiple war files

I'm not sure if you understood correctly, but the HttpSession is different for each user (browser session), and for each application as well, AFAIK, so you can't use it to share data.

Basically, you need communication between your web applications.
You could have one war to act as data manager for your UserSession, and all other wars communicating to this one. The data manager application needs to expose a service, e.g. UserSessionManager that can be accessed via other applications.

JNDI is a traditional solution for this. Spring has some helpers for this, but the JNDI API is not too complicated either. In the data manager war, you could do something like this in an initialization method:

DataManager mgr = new DataManagerImpl(...);
InitialContext ic = new InitialContext();
ic.rebind("java:global/env/datamanager", mgr);

The interface and the data objects you use needs to be put in a jar that is shared in all 'client' wars, the implementation is only in the data manager war. In your client wars, you can then do:

InitialContext ic = new InitialContext();
DataManager mgr = (DataManager)ic.lookup("java:global/env/datamanager");

Hope this helps,
Geert.

Sessions Sharing between two web applications : tomcat

You can find documentation for Tomcat clustered sessions here.

Sharing session data between two war files

While session replication indeed can be done in Tomcat (see here) I really suggest you to avoid this type of issues by eliminating the session altogether.

This session replication is an approach that was somewhat common before ~15-10 years, but nowadays when we have a lot of servers running in parallel to serve user requests and have elastic clusters, this approach is not good enough because basically it doesn't scale well.

There are many ways to achieve what you want, though:

1. Use a shared database to store the session information. Add some session Id to the response and require the client to pass this id back into all subsequent request along the session. Then execute a query to the Database by this Id and retrieve all the session information.
   This solution also doesnt really scale well, but then you can shard the session information if the db permits to do so...
2. Use Redis/Aerospike to save the session information of the currently connected user. somewhat like DB approach, but since redis run in-memory it will be much faster. In general, this approach can be used in conjunction with 1 where redis is an in-memory cache.
3. Encrypt the session information or even just sign cryptographically and send back to client. Client will have to supply this information along with the request without knowing which server will actually serve this request.
   Without delving into cryptography I'll just state that encryption can be done if you don't want client to see the session information (despite the fact that this is the user whose information is supplied) and signature is used to prevent tempering the data (while sending it back to server).
   The data can be supplied to server from client via Header or cookie for instance.

---

Related Topics