I've been looking for the workaround of this problem for rather plenty of time and no result, so I ask question here.

Simply speaking, I'm using a CDI SessionScoped Bean User in my project to manage user information and display them on jsf pages. Also container-managed j_security_check is used to resolve authentication issue.

Everything is fine if first logout with session.invalidate() and then login in the same browser tab with a different user. But when I tried to directly login (through login.jsf) with a new user without logout beforehand, I found the user information remaining unchanged.

I debugged and found the User bean, as well as the HttpSession instance, always remaining the same if login with different users in the same browser, as long as session.invalidate() not invoked. But oddly, the session id did modified, and I've both checked in Java code and Firebug.

org.apache.catalina.session.StandardSessionFacade@5d7b4092
StandardSession[c69a71d19f369d08b5dddbea2ef0]
attrName = org.jboss.weld.context.conversation.ConversationIdGenerator : attrValue=org.jboss.weld.context.conversation.ConversationIdGenerator@583c9dd8
attrName = org.jboss.weld.context.ConversationContext.conversations : attrValue = {}
attrName = org.jboss.weld.context.http.HttpSessionContext#org.jboss.weld.bean-Discipline-ManagedBean-class com.netease.qa.discipline.profile.User : attrValue = Bean: Managed Bean [class com.netease.qa.discipline.profile.User] with qualifiers [@Any @Default @Named]; Instance: com.netease.qa.discipline.profile.User@c497c7c; CreationalContext: org.jboss.weld.context.CreationalContextImpl@739efd29
attrName = javax.faces.request.charset : attrValue = UTF-8

org.apache.catalina.session.StandardSessionFacade@5d7b4092
StandardSession[c6ab4b0c51ee0a649ef696faef75]
attrName = org.jboss.weld.context.conversation.ConversationIdGenerator : attrValue = org.jboss.weld.context.conversation.ConversationIdGenerator@583c9dd8
attrName = com.sun.faces.renderkit.ServerSideStateHelper.LogicalViewMap : attrValue = {-4968076393130137442={-7694826198761889564=[Ljava.lang.Object;@43ff5d6c}}
attrName = org.jboss.weld.context.ConversationContext.conversations : attrValue = {}
attrName = org.jboss.weld.context.http.HttpSessionContext#org.jboss.weld.bean-Discipline-ManagedBean-class com.netease.qa.discipline.profile.User : attrValue = Bean: Managed Bean [class com.netease.qa.discipline.profile.User] with qualifiers [@Any @Default @Named]; Instance: com.netease.qa.discipline.profile.User@c497c7c; CreationalContext: org.jboss.weld.context.CreationalContextImpl@739efd29
attrName = javax.faces.request.charset : attrValue = UTF-8

Above block contains two successive logins and their Session info. We can see that the instance(1st row) the same while session id(2nd row) different. Seems that session object is reused to contain different session id and CDI framework manages session bean life cycle in accordance with the session object only(?).

I'm wondering whether there could be only one server-side session object within the same browser unless invalidated?

Since I'm adopting j_security_check I fancy intercepting it and invalidating old session is not so easy. So is it possible to accomplish the goal without altering the CDI+JSF+j_security_check design that one can relogin with different account in the same or different tab within the same browser?

Really look forward for your response.

More info: Glassfish v3.1 is my appserver.