I'd suggest a Filter that synchronizes on a private Object stashed on
the HttpSession.
(In general, avoid synchronizing on the HttpSession itself).

-- Adam


On 10/18/05, Mathias Broekelmann (JIRA)
<[email protected]> wrote:
>      [ http://issues.apache.org/jira/browse/MYFACES-543?page=all ]
>
> Mathias Broekelmann closed MYFACES-543:
> ---------------------------------------
>
>     Resolution: Won't Fix
>
> Marcus try to implement your own FacesServlet by using the code from the 
> existing one. IMO your problem is very specific and can´t be addressed in 
> myfaces.
>
> Synchronizing the state of user session beans can only be solved by the user. 
> Rendering the view does not guarantee that the user objects will not change. 
> In fact if two request are processed at the same time (one of them changing 
> the data, the other one is displaying the data) it is likly that the second 
> response is corrupted since the data changed during the rendering.
>
> If you use UIData components you will see some strange things. Since UIData 
> components maintains a state during processing and rendering and can´t be 
> synchronized. So you definitly need different component instances for each 
> request. Reusing an existing component tree may not be working since jsf 
> defines no lifecycle (like the one for servlets) for the components. Some 
> components don´t clean up their state if processing is finished.
>
> > Problems handling simultaneous request from the same session
> > ------------------------------------------------------------
> >
> >          Key: MYFACES-543
> >          URL: http://issues.apache.org/jira/browse/MYFACES-543
> >      Project: MyFaces
> >         Type: Bug
> >   Components: Implementation
> >     Versions: 1.0.9m9
> >     Reporter: Marcus Schiesser
> >      Fix For: Nightly
> >  Attachments: semaphore.patch, sync.patch
> >
> > If someone tries to do simultaneous client requests from the same 
> > HttpSession instance (i used a direct resubmit in the form tag's onsubmit 
> > handler which leads to two simultaneous requests) it will lead to 
> > concurrent access problems.
> > During my tests, it almost any time crashed in the UIViewRoot 
> > implementation. The reason is that it is not thread-safe which could be 
> > easily solved by synchronising the 4 process.... methods and the queueEvent 
> > method.
> > But the question is where to put the synchronisation, i also tried 
> > synchronising the service method of the FacesServlet class, so that only 
> > one HttpSession could run at the time (IMHO something desirable). That way 
> > the simultaneous request are processed one after the other.
> > But a further question arises then: How MyFaces handles the problem if two 
> > identically request are processed in the lifecycle - is this appart from 
> > the rendering (in my tests SocketExceptions occured as the connection has 
> > been reset before) a problem? Does it affect the state?
> > What are your opinions concerning this topic?
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
>    http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>    http://www.atlassian.com/software/jira
>
>

Reply via email to