myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kočí (JIRA) <>
Subject [jira] [Commented] (MYFACES-3117) Current server state saving implementation prevents multi-window usage
Date Wed, 27 Apr 2011 19:42:03 GMT


Martin Kočí commented on MYFACES-3117:

Too bad that sychronizer token  for JSF is not specified yet (JAVASERVERFACES_SPEC_PUBLIC-559
has my vote). I think that viewSequence used in myfaces codebase is de-facto token and with
we can use it for detection if request with same token is processed or not. 

Timeout for saved view: I think that does not solve the problem: user can wait between requests
seconds or hours, timeout makes behaviour of app undeterministic.

A new param org.apache.myfaces.REMOVE_RESTORED_VIEW_STATE with default false can solve this
problem for now. Applications where double submit problem is solved (for example with Seam
UIToken or with AJAX-only requests - ajax has own queue) can set this param to true without
side effects.

> Current server state saving implementation prevents multi-window usage
> ----------------------------------------------------------------------
>                 Key: MYFACES-3117
>                 URL:
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: General
>    Affects Versions: 2.0.6-SNAPSHOT
>         Environment: myfaces core trunk
>            Reporter: Martin Kočí
>            Priority: Critical
>         Attachments: MYFACES-3117.patch
> Problem:
> open two tabs (or windows) in browser with view:
> <h:body>
>         <h:form id="formId">
>             <h:commandButton value="Click me 20x!" />
>         </h:form>
>  </h:body>
> then click the button on the first tab 20x or more -> then click the button on the
second tab -> you will get the most beloved ViewExpiredException.
> Reason:
> oam.SerializedViewCollection drops the saved state for 2. tab from map. 
> Suggestion:
> remove the successfully restored view state from map. This can be done, because each
SerializedViewKey is unique over *all requests* for one HttpSession -  see DefaultFaceletsStateManagementHelper.nextViewSequence(FacesContext).
Because each request has unique sequence number, we can the "just restored" one remove from
the map, because it can never come from  client again.
> Open question: the previous statement is true except the double submit problem: 	JAVASERVERFACES_SPEC_PUBLIC-559.
In this case, server can process same request (with the same sequence number) twice.

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message