Looking at the code that is referenced by the link below I see the following:
private HttpSession getSession()
{
return _httpRequest.getSession(false);
}
Now based on this understanding:
When you say getSession(true), this method will check whether already a session
is existing for the user. If a session is existing, it will return that session
object, OTHERWISE WILL CREATE A SESSION OBJECT EXPLICITLY AND RETURN TO THE
CLIENT. When you say getSession(false), this method will check whether a
session is existing. If yes, then it returns the reference of that session
object, OTHERWISE IT WILL RETURN 'null'.
So the above code can return a null for the session - I am not sure what the
original intent of the method is as I do not see any JavaDocs with it.
Session Manage is handled by JSF, so I assume then that the SessionMap class is
part of the Session Manage process of JSF.
It would appear that the JSF library is making a call to set the attribute on a
session, therefore it should trigger the session replication correctly.
The issue then could be is that the session size is so large that it does not
have the ability to complete the task in the event of a user moving to a
different IP address.
-----Original Message-----
From: Leonardo Uribe [mailto:[email protected]]
Sent: Tuesday, September 27, 2011 12:28 PM
To: MyFaces Discussion
Subject: Re: Issues with MyFaces and Clusters
Hi
2011/9/27 Rohit Kelapure <[email protected]>:
> Leonardo,
>
> Updating this sessionMap object doesn't mean anything to the session.
> It has to be the sessionMap object updated within the session. Something
> like this -
>
> session.put("sessionMap", object);
>
Look this class:
http://svn.apache.org/repos/asf/myfaces/core/branches/1.1.x/impl/src/main/java/org/apache/myfaces/context/servlet/SessionMap.java
In JSF, the "sessionMap" is a wrapper for the session object, so call
sessionMap.put will effectively call
_httpRequest.getSession(true).setAttribute(key, value). It is ok.
regards,
Leonardo Uribe
> --Thanks,
> Rohit
>
>
> On Mon, Sep 26, 2011 at 10:24 PM, Leonardo Uribe <[email protected]> wrote:
>
>> Hi
>>
>> 2011/9/26 Boyd, David (Corporate) <[email protected]>
>>
>> > So just to be clear
>> >
>> > 1. Based on the code snipit it appears that indeed myfaces is doing thing
>> > as expected.
>> >
>> >
>> Yes.
>>
>>
>> > 2. Are stating that the issue I am seeing is a know bug with Websphere 7?
>> > If so can you provide a link. I was searching the IBM site but did not
>> > have any success in locating any issue list.
>> >
>> >
>> I don't know if it is a known bug. All I can say is myfaces with other
>> servers in a cluster configuration work as expected, so I suppose based on
>> the evidence it is a bug on Websphere.
>>
>> regards,
>>
>> Leonardo
>>
>>
>> >
>> >
>> > Thanks
>> > -David Boyd
>> >
>> > (Sent via BlackBerry)
>> >
>> > ----- Original Message -----
>> > From: Leonardo Uribe [mailto:[email protected]]
>> > Sent: Monday, September 26, 2011 09:47 PM
>> > To: MyFaces Discussion <[email protected]>
>> > Subject: Re: Issues with MyFaces and Clusters
>> >
>> > Hi
>> >
>> > I have checked the latest code (and 1.1.7 code) and it seems to be
>> correct.
>> > See:
>> >
>> >
>> >
>> http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/jsp/JspStateManagerImpl.java
>> >
>> > the following lines:
>> >
>> > protected void saveSerializedViewInServletSession(FacesContext
>> context,
>> > Object
>> serializedView)
>> > {
>> > Map<String, Object> sessionMap =
>> > context.getExternalContext().getSessionMap();
>> > SerializedViewCollection viewCollection =
>> > (SerializedViewCollection) sessionMap
>> > .get(SERIALIZED_VIEW_SESSION_ATTR);
>> > if (viewCollection == null)
>> > {
>> > viewCollection = new SerializedViewCollection();
>> > sessionMap.put(SERIALIZED_VIEW_SESSION_ATTR, viewCollection);
>> > }
>> > viewCollection.add(context, serializeView(context,
>> serializedView));
>> > // replace the value to notify the container about the change
>> > sessionMap.put(SERIALIZED_VIEW_SESSION_ATTR, viewCollection);
>> > }
>> >
>> > Look the last line that force the collection to be stored again on the
>> > session, to notify the container about the change. Maybe since the same
>> > instance is stored, by some reason WebSphere is not notifying the change
>> > and
>> > cause the problem you described. I think a workaround is create a custom
>> > state manager extending from myfaces one and writing something else on
>> the
>> > session, but in practice it is a bug in WebSphere, so a fix should be
>> done
>> > there.
>> >
>> > regards,
>> >
>> > Leonardo Uribe
>> >
>> > 2011/9/26 Rohit Kelapure <[email protected]>
>> >
>> > > David,
>> > >
>> > > Please take a look at
>> > >
>> > > Update All Session Attributes option - Horrible for performance, but
>> > fixes
>> > > issues like this.
>> > >
>> > >
>> >
>> http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzamy%2F50%2Fadmin%2Fhelp%2Fuprs_rtuning_parameters.html
>> > >
>> > > --Thanks,
>> > > Rohit
>> > >
>> > > On Mon, Sep 26, 2011 at 3:09 PM, Boyd, David (Corporate) <
>> > > [email protected]> wrote:
>> > >
>> > > > I am having some issues with clustering an application with session
>> > > > affinity enabled on Websphere Application Server.
>> > > >
>> > > >
>> > > >
>> > > > We are using:
>> > > >
>> > > >
>> > > >
>> > > > MyFace 1.1.7
>> > > >
>> > > > Tomahawk 1.1.5
>> > > >
>> > > > JDK 1.5
>> > > >
>> > > > WebSphere 7 - Fix Pack 13
>> > > >
>> > > >
>> > > >
>> > > > I am wondering if this is a known issue with this version of My
>> Faces.
>> > > >
>> > > >
>> > > >
>> > > > What appears to be happening is that in the application, when a
>> session
>> > > > object is accesses and the data is changed, the change event is not
>> > > > being triggered and therefore the change is not being pushed out to
>> all
>> > > > the servers in the cluster.
>> > > >
>> > > >
>> > > >
>> > > > It looks like this version of my faces is accessing the session
>> object
>> > > > via the getter but, it is making a change to the reference and
>> > therefore
>> > > > not calling the setter method.
>> > > >
>> > > >
>> > > >
>> > > > Looking for some confirmation on this issue or possible a
>> configuration
>> > > > that needs to be done.
>> > > >
>> > > >
>> > > >
>> > > > Thanks
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> >
>>
>
