Actually Dave, I would follow Rohit's suggestion. Leonardo, that's appears to be the state saving code. I think, essentially, the issue is that when objects are modified, they need to be set on the session again so that the container knows to re-serialize them for failover.
AFAIK, there is no known failover issue with websphere provided these attributes are re-set when the object is modified. Sent from my iPhone On Sep 26, 2011, at 7:59 PM, "Boyd, David (Corporate)" <[email protected]> wrote: > So just to be clear > > 1. Based on the code snipit it appears that indeed myfaces is doing thing as > expected. > > 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. > > > > 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 >>> >>> >>> >>> >>> >>> >>> >>> >>
