Shared session data, JBAS-1909

[starksm64]

Regarding http://jira.jboss.com/jira/browse/JBAS-1909(Feature Request - HttpSession sharing between WAR modules), what is the possibility of implementing this via JBossCache using a custom session manager that is essentially a variation of the clustered version?

[julien1]

This would be great benefit for JBoss Portal.

The current session manager based on JBoss Cache would fit here. It is just a matter of having two managers use a same cache region instead of distinct ones.

I don't know how configuration is done in others appserver, but I think a reasonable thing would be to add that to the jboss webapp metadata in order
to enable the webapp to use a common id for this.

[brian.stansberry]

From what I read in the BEA and IBM docs referenced in JBAS-1909, it looks like they scope their shared session at the level of the EAR. That approach would be tricky for us, as AFAIK a war deployment has no knowledge of any metadata associated with its enclosing ear (please correct me if I'm wrong).

We could add an element to jboss-web.xml to name the set of applications over which the session is shared.

[starksm64]

Yes, this is wrong. The DeploymentInfo is a tree that maps to whatever the root deployment is. You can walk the tree to find the root to use as a shared reference point. The problem with this in the current deployment scheme is that the DeploymentInfo is generally thrown away so it would have to be introduced as part of the runtime layer. Just doing this is problem a bad idea.

More generally we need a runtime metadata tree that can be used for things like the java:comp/env ENC contexts rather than keying these to thread context class loaders, shared/scoped data levels, etc. This tree would be pushed into the request layer at runtime via a thread local or the like request level injection.

[brian.stansberry]

We'd also need to distinguish between distributed and non-distributed apps; i.e. use a different JBossCache instance that doesn't replicated if all that was needed was session sharing.

The IBM note says they don't allow apps that use shared sessions to be distributed, due to the risk of concurrent modifications.

Our current implementation would have concurrency risks as well, even on a single machine. The user application works with a local version of the session object during the course of a request. At the end of the request, if the session has been made dirty, it's marshalled into a byte[] and put into the cache. If we have more than 1 manager accessing the same cache region, there is no common unmarshalled session object that can be synchronized on to control concurrency.

Storing the session using TreeCacheAop would help with this, as it would allow a single shared session object.

[starksm64]

The metadata of the web deployment should be available to the session manager. We should probably just generalize the jboss session manager interface to accept the deployment WebMetaData if we don't already have this.

Its a bit of a contested issue as to whether the container should be providing thread safe access to the session, even though servlets are not thread-safe by definition. The problem is that a servlet just locking on the session object may not be sufficient. In this current usecase two wars accessing a "shared" session are not likely to see the exact same session java object. The sharing is done under the application level session instance. Because of this, I think we have to provide support for thread-safe access.

[belaban]

I assigned this issue to Ben. Brian/Ben, do you think we need to move this over to the Clustering JIRA ? Or should it be in JBossCache ? Your call, Ben

[wikijuarezjunior]

Hello there,

Could anybody please inform the current status of this request?

I'm looking forward to your reply.

Thanks a lot!

[brian.stansberry]

This is going to take a significant design and development effort. Some design thinking has been done, but a lot more is needed.

Discussed this with Ben Wang this morning and we don't see this being implemented in 4.0.4. Probably 5.0 Final, or 4.0.5 if there is one and it comes out before 5.0 Final.

[ben.wang]

Here is proposal discussed by me and Brian:

1. It should be possible to leverage our current implementation of JBossCacheManager and use JBossCache as a central store (but only with local mode turned on). We will need a special SharedSessionJBossCacheManager and SharedSession (either a sub-class of Session or ClusteredSession).

2. We can use "emptySessionPath" in Tomcat Connector such that the context path is always "/" for web app. After that, SharedSessionJbossCacheManager will perform a special lookup when the cookie and session id is presented.

3. This can potentailly be cluster-aware as well. But I think first phase is just local only.

4. As for configuration, we will add a "SharedSession" flag in jboss.xml. How that flag will propagate down to JBossManager still needs to be determined. But it should be doable.

Thoughts?

-Ben

[starksm64]

So your envisioning that the session id with a shared cookie?

What about just a shared section in the session that maps onto the cache.

<jboss-web>
 <shared-session-attribute>shared</shared-session-attribute>
</jboss-web>

 HttpSession session = ...;
 Hashtable sharedData = (Hashtable) session.getAttribute("sharedData")

[ben.wang]

This is ok but I am thinking without sharing cookie, when doing a findSession(ID) to retrieve the session, how can the SharedSessionJbossManager determine 1) whether it is truly a new session, 2) if it shared, where to look for that data?

[wikijuarezjunior]

Hello Brian, Ben and Scott,

I discussed the proposal with our manager and team members here and I have some issues i'd like to share with you.

Currently, we are using JBoss series 3.2.x but we are already performing some tests to migrate to JBoss 4.0.x.

Also, we are in process of deploying our application in a JBoss cluster using 3.2.x at first.

There's no problem if the first phase of session sharing is "local only" but this is not going to help us mainly because we're getting ready to take our cluster to production. But we do understand the efforts you're going to undertake and we don't want to bother you in any way.

But please be aware that we need the replication for a clustered environment.

Also, considering that we're moving to JBoss series 4.0.x, implementing the session sharing in JBoss 4.0.5, if there's one, would be great!

At last, the "SharedSession" flag in jboss.xml sounds good and resembles similar flags in WebLogic and WebSphere.

Unfortunately we can't help in the implementation issues considering that we do not know the implementation details and internals of JBoss.

We'll be watching this post and please let us know if we can provide any further information you may need.

Best Regards,

[brian.stansberry]

Hi Juarez,

The difficulty with making it clustered is in dealing with concurrency issues if multiple browser windows are dealing with the same shared session while contacting different server instances.

Is that kind of behavior one of your requirements? Or are you looking at clustering solely in terms of failover -- if one node fails, the session is available on another. In this case, the session would only be accessed on one node at a time, so the management problem is much simpler.

BTW, with a common session id, most load balancers would of course pin all browser requests to the same server instance, although a set of webapps could get around that if that wanted to.

[wikijuarezjunior]

Hello Brian,

Thanks a lot for your reply.

No Brian, this kind of behavior (multiple browser windows dealing with the same shared session while contacting different server instances) is not one of our requirements.

Ye, we're looking to clustering in terms of failover only (if one node fails, the session is available on another).

You're right, this is what we're looking for. Is it possible to implement that?

We're looking forward to you reply. Thanks in advance!

Juarez