[
https://issues.apache.org/jira/browse/MYFACES-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025972#comment-13025972
]
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: https://issues.apache.org/jira/browse/MYFACES-3117
> 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: http://www.atlassian.com/software/jira
